Re: Hg vs Git

On Mon, Nov 28, 2016 at 4:42 AM, Russel Winder <[email protected]> wrote:
> On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
>> > The point here is that someone can mutate a branch locally and then
>>
>> force it to the mainline.
>>
>> No, that is specifically what protected branches prevent. If "master"
>> is
>> protected, then no one, not even an admin, can re-write history and
>> force
>> push to it.
>
> So if BitBucket supports this, the admins for the mainline SCons and
> SCons-Contrib repositories should mark all the branches as protected?

Not necessarily "all" of the branches, but definitely the ones that
are final/deliverable (e.g. "master" in git parlance). I also
recommend protecting long-lived feature branches, e.g. the Python 3
effort, where multiple people may be working on it for quite a while.

>> Personally, I find the rewriting extremely powerful for my local
>> development - I can re-arrange, split, and join commits in my feature
>> branch before it is merged into master. Very few people are
>> interested in
>> rewriting history of a published tree.
>
> I have never been a user of history rewriting as I tend to publish all
> my repositories all the time. Maybe my workfow and approach is wrong,
> and that I should keep all work private and so rebasable and squashable
> in both Hg and Git until the point of publishing for the pull request?

IMO, it's all about a published branch policy for the project. For example:
- master - Stable at all times; protected; periodically tagged for
major releases
- devel - Bleeding edge; mostly stable; protected; periodically merged
into master at stable points
- (everything else) - In-progress feature/issue branch; **not
protected** and may be rebased/rewritten at any time

This allows you to say "hey guys, check out my WIP branch", but with a
disclaimer that it may be rewritten, giving you the power to go back
and change things based on code review.