[gentoo-dev] Re: On banning merge commits

[Duncan <1i5t5.duncan@cox.net>]

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

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

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