[gentoo-dev] Re: On banning merge commits

[Duncan]

Rich Freeman posted on Sun, 08 May 2016 08:34:37 -0400 as excerpted:

> merges shouldn't just be used for random pull-requests.  However, when
> you're touching multiple packages/etc they should be considered.  They
> should also be considered if for some reason you had a bazillion commits
> to a single package that for some reason shouldn't be rebased.
> I imagine that they'll be a small portion of commits as a result.
> However, for the situations where they're appropriate they make a lot of
> sense.
> 
> This was some of Duncan's point, but I will comment that we'll never
> have as clean a history as the kernel simply because we don't have a
> release-based workflow with the work cascading up various trees.  The
> kernel is almost an ideal case for a merge-based workflow.  I imagine
> that half of Gentoo's commit volume is random revbumps and keyword
> changes and that is just going to be noise no matter what.  If we were
> release-based we could do that stuff in its own branch and merge it all
> in at once, but that just isn't us.

Recognized and agree.  Thanks.

-- 
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

[gentoo-dev] Re: On banning merge commits

[Duncan]

Rich Freeman posted on Sun, 08 May 2016 07:57:17 -0400 as excerpted:

> I think that bans are better used for bad attitude than for mistakes.

[Stepping back from the immediate discussion at hand...]

The above is wisdom, arguably, quotable sig-level wisdom!

Certainly wisdom enough to be worth emphasizing by calling it out in a 
quote as I'm doing here. =:^)

-- 
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

Re: [gentoo-dev] Re: On banning merge commits

[Dirkjan Ochtman]

On Sun, May 8, 2016 at 11:25 AM, Kent Fredric  wrote:
> The essential idea being to minimise the amount of congnitive effort a
> human has when trying to explore the history and understand what
> "actually happened" from a master perspective.
>
> "Long histories that go for days only to merge one commit" tend to
> harm this, and I think that's the essential irritation.

This makes sense to me.

Personally, I think rebases are easy in the vast majority of the cases
(specificially for our gentoo tree, where actual conflicts are often
unlikely). However, for long-running branches (either in time, which I
think doesn't happen that often, or in work), making an explicit merge
could still make sense.

(I guess this is slightly different than somehow limiting the length
of the left-sized twig.)

Cheers,

Dirkjan

[gentoo-dev] Re: On banning merge commits

[Duncan]

Kent Fredric posted on Sun, 08 May 2016 21:25:38 +1200 as excerpted:

> On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote:
>> 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.
> 
> I think the annoyance is more having two histories, where on one side,
> you've got the high-traffic gentoo work flow happening, and then  you
> have a merge commit 
> 
> And that merge commit may have only a single commit on it, and its
> parent is god-knows how many days old.
> 
> So the "graph" looks *massive* when it is really only a single commit
> and its merge commit.
> 
> I think the most productive thing here is not to ban "merge commits" as
> such, but ban merge commits where the "merge base" ( that is, the common
> ancestor of the left and right parents of the merge commit ) leaves a
> significant number of commits on the "left" side of the equation. [...]

> "Long histories that go for days only to merge one commit" tend to harm
> this, and I think that's the essential irritation.

OK, that I can agree with. =:^)

-- 
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

Re: [gentoo-dev] Re: On banning merge commits

[Kent Fredric]

On 8 May 2016 at 20:58, Duncan <1i5t5.dun...@cox.net> wrote:
> 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.


I think the annoyance is more having two histories, where on one side,
you've got the high-traffic
gentoo work flow happening, and then  you have a merge commit 

And that merge commit may have only a single commit on it, and its
parent is god-knows how many days old.

So the "graph" looks *massive* when it is really only a single commit
and its merge commit.

I think the most productive thing here is not to ban "merge commits"
as such, but ban merge commits where the "merge base" ( that is, the
common ancestor of the left and right parents of the merge commit )
leaves a significant number of commits on the "left" side of the
equation.

Personally, I could live with "0 commits on left", because that would
give a bunching effect.

The "Real History" would still be linear if you followed only the
right parents, but you'd get a simplified view with grouping if you
followed only the left parents.

However, a limit of say, 10 commits on left, I could also live with.

The essential idea being to minimise the amount of congnitive effort a
human has when trying to explore the history and understand what
"actually happened" from a master perspective.

"Long histories that go for days only to merge one commit" tend to
harm this, and I think that's the essential irritation.

-- 
Kent

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

[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. 

>   Original Message
> From: Michał Górny Sent: Sunday, May 8, 2016 13:09 To: Patrice Clement
> Reply To: gentoo-dev@lists.gentoo.org Cc: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] On banning merge commits
> 
> On Sun, 8 May 2016 01:52:22 +0200 Patrice Clement <monsie...@gentoo.org>
> 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  
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