1 |
On 8 May 2016 at 20:58, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> Or to put it a different way, if we're not going to use git's rich |
3 |
> distributed branch development and tracking, forcing everything to single |
4 |
> chain on the main tree, why did we bother switching to git in the first |
5 |
> place? That was available on cvs, or if we wanted more features, |
6 |
> subversion, etc. |
7 |
|
8 |
|
9 |
I think the annoyance is more having two histories, where on one side, |
10 |
you've got the high-traffic |
11 |
gentoo work flow happening, and then you have a merge commit .... |
12 |
|
13 |
And that merge commit may have only a single commit on it, and its |
14 |
parent is god-knows how many days old. |
15 |
|
16 |
So the "graph" looks *massive* when it is really only a single commit |
17 |
and its merge commit. |
18 |
|
19 |
I think the most productive thing here is not to ban "merge commits" |
20 |
as such, but ban merge commits where the "merge base" ( that is, the |
21 |
common ancestor of the left and right parents of the merge commit ) |
22 |
leaves a significant number of commits on the "left" side of the |
23 |
equation. |
24 |
|
25 |
Personally, I could live with "0 commits on left", because that would |
26 |
give a bunching effect. |
27 |
|
28 |
The "Real History" would still be linear if you followed only the |
29 |
right parents, but you'd get a simplified view with grouping if you |
30 |
followed only the left parents. |
31 |
|
32 |
However, a limit of say, 10 commits on left, I could also live with. |
33 |
|
34 |
The essential idea being to minimise the amount of congnitive effort a |
35 |
human has when trying to explore the history and understand what |
36 |
"actually happened" from a master perspective. |
37 |
|
38 |
"Long histories that go for days only to merge one commit" tend to |
39 |
harm this, and I think that's the essential irritation. |
40 |
|
41 |
-- |
42 |
Kent |
43 |
|
44 |
KENTNL - https://metacpan.org/author/KENTNL |