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

[Kent Fredric <kentfredric@gmail.com>]

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