Re: [gentoo-dev] On banning merge commits

[Kent Fredric]

On 8 May 2016 at 23:57, Rich Freeman <rich0@g.o> wrote:
> How does a merge make it any easier/harder to mess up the entire tree?
>  I can see how they can make the history easier/harder to read but in
> the end I believe the content of the tree itself ends up being
> whatever was in the index when you made the commit.
>
>>
>> * The only alternative would be to come up with criteria for merges and
>> actually enforce them (meaning, if you mess up the tree more than twice you
>> lose your push access. Hello QA.).
>>
>
> Here is the other only alternative: use rebase commits when they're
> most appropriate, and use merge commits when they're most appropriate,
> and publish easy-to-understand guidelines for when each is the case.
> I don't really see a need for hard rules unless we think devs can
> actually comply with them.  Do we really want somebody to lose their
> commit access because they pushed a string of rebased commits that
> might have been more appropriate as a single merge commit?
>
> Both types of commits have their place.  I think that bans are better
> used for bad attitude than for mistakes.  I don't think you need a
> 100% rigid rule to enforce a ban either - this isn't a court of law
> (and I think many of the failings of courts of law result from the
> rigid application of rules, but that is a different matter).

I'd probably say any case where you have to resolve a conflict in the
merge commit is a clear indicator that the right branch needed
rebasing prior to merging, either way.

mostly, because it means some change on the right side becomes
transiently dependent on a change on the left side, and its obscured
by the resolution mid-merge.

( And such conflicts tend not to be even obvious that they've existed
when traversing a history with merge commits, because "merge diffs"
get suppressed by default ).

And its usually not clear what the "Solution" is when you're simply
comparing 2 heads.

With a rebase, you know exactly what the expected change is at the
commit that makes the change, and the rebase lets you see what the
existing state was at the time of applying the change.

Merges without conflicts however are much less contentious.

In short, if you get a merge conflict, then somebody needs to pay more
attention to what happened on one side of the changes, and one side of
that equation should be rebased to avoid that conflict.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL