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