Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: On banning merge commits
Date: Sun, 08 May 2016 10:21:58
Message-Id: pan$10e4a$77bed5$ffe3838a$eee88f7a@cox.net
In Reply to: Re: [gentoo-dev] Re: On banning merge commits by Kent Fredric
1 Kent Fredric posted on Sun, 08 May 2016 21:25:38 +1200 as excerpted:
2
3 > On 8 May 2016 at 20:58, Duncan <1i5t5.duncan@×××.net> wrote:
4 >> Or to put it a different way, if we're not going to use git's rich
5 >> distributed branch development and tracking, forcing everything to
6 >> single chain on the main tree, why did we bother switching to git in
7 >> the first place? That was available on cvs, or if we wanted more
8 >> features, subversion, etc.
9 >
10 > I think the annoyance is more having two histories, where on one side,
11 > you've got the high-traffic gentoo work flow happening, and then you
12 > have a merge commit ....
13 >
14 > And that merge commit may have only a single commit on it, and its
15 > parent is god-knows how many days old.
16 >
17 > So the "graph" looks *massive* when it is really only a single commit
18 > and its merge commit.
19 >
20 > I think the most productive thing here is not to ban "merge commits" as
21 > such, but ban merge commits where the "merge base" ( that is, the common
22 > ancestor of the left and right parents of the merge commit ) leaves a
23 > significant number of commits on the "left" side of the equation. [...]
24
25 > "Long histories that go for days only to merge one commit" tend to harm
26 > this, and I think that's the essential irritation.
27
28 OK, that I can agree with. =:^)
29
30 --
31 Duncan - List replies preferred. No HTML msgs.
32 "Every nonfree program has a lord, a master --
33 and if you use the program, he is your master." Richard Stallman