[gentoo-dev] Re: On banning merge commits

[Duncan]

cbergstrom posted on Sun, 08 May 2016 13:44:43 +0800 as excerpted:

> Don't be crazy - I know many developer groups which dislike merge
> commits. That nonlinear work flow is just a mess long term.

Said by someone who apparently can't figure out reasonable quote then 
reply-in-context, or even appropriate quote nesting, either. <shrug>

>   Original Message
> From: Michał Górny Sent: Sunday, May 8, 2016 13:09 To: Patrice Clement
> Reply To: gentoo-dev@l.g.o Cc: gentoo-dev@l.g.o
> Subject: Re: [gentoo-dev] On banning merge commits
>
> On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement <monsieurp@g.o>
> wrote:
>
>> Hi gents
>>
>> After yet another discussion about git in the #gentoo-dev channel
>> tonight, the topic of merge commits came up for the umpteenth time.
>>
>> We all seem to agree merge commits are really bad design, add clutter
>> to the log graph after a while and should be banned altogether from
>> reaching the central repository.
>>
>> As of now, no policy is in place yet to keep developers from pushing
>> merge commits.
>>
>> What is the correct course of action? I would very much like it to be
>> worded in a document (GLEP and/or Wiki page) so that confusion is
>> avoided and we all are on the same page on this topic.
>
> You start by accepting my retirement.

Agreed with mgorny here.

In fact, I'd suggest banning *non-*merge push-commits.  It's forcing the 
rebases that is really bad design, removing useful information from the 
log graph, etc.

The reason gentoo's git logs are such a mess now is that they're mostly 
flat.  Initial commits are normally one atomic issue per initial commit, 
good, but then instead of naturally grouping them by subject with a well 
commented merge commit, as is done for example with the mainline kernel 
tree, they're unnaturally forced into a flat list by rebases instead of 
the more natural merges, horribly *bad*!

Of course that loses all the rich information that the merges carry, 
including, when merges are done right, grouping individual atomic commits 
by general task/project, and appropriate merge comments outlining what 
was actually merged.

With the kernel I can git log --graph ORIG_HEAD.. and by default search 
only for merges into the mainline/lefthand master branch.  That gives me 
a very good overview of what subsystems were merged, and for the ones 
that interest me, I can read the merge commit comment and have a good 
idea what was merged from that subsystem.  For the ones that are more 
interesting, I can drill down into the merge and read individual commit 
comments.  If even that isn't enough, I can easily git show <commit> 
using the commit ID from the log, and get the full diff.

Try doing that with gentoo.  It doesn't work because everything's flat; 
there's too few merge commits.  For instance, I've no interested in arm, 
and with the kernel git log, I can skip the majority of arm-affecting-
only commits by just skipping the merge commits as soon as I see it's 
from the arm tree, while with the gentoo git log, all those arm 
stabilizations appear as hundreds of individual flat commits on the main 
branch, instead of a small handful of merge-commits, with merge-commit 
comments such as "arm stabilizations for app-foo/bar and deps".

So on gentoo, what I end up doing instead is seeing what packages want to 
update, and only searching the git log for the interesting ones.  Works 
well enough for that, but I've effectively no overview of what's going on 
in general as I do for the kernel tree, as I miss all the interesting 
commits that didn't happen to show up as package update candidates spit 
out by portage, even in areas I'd otherwise track rather heavily, like 
kde, where I track the kde overlay git log, but miss the gentoo repo side 
due to the problems created by lack of appropriate merge commits as 
explained above.


Or to put it a different way, if we're not going to use git's rich 
distributed branch development and tracking, forcing everything to single 
chain on the main tree, why did we bother switching to git in the first 
place?  That was available on cvs, or if we wanted more features, 
subversion, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman