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 |