Jeff King <p...@peff.net> writes: > That works for the diagram in the code: > > | *---. > | |\ \ \ > |/ / / / > x 0 1 2 > > where one of the parent lines is collapsing back to the left. But not > for this more mundane case: > > | *-----. commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e > | |\ \ \ \ Merge: fc54a9c30c 9e30dd7c0e c4b83e618f 660265909f b28858bf65 > | | | | | | > > where we go straight down. I'm not sure I've fully grasped it, but it > feels like that distinction is the source of the off-by-one. I'm not > sure how to tell the difference here, though. I think it relies on the > next commit on the left-hand line being the same as the first parent (or > maybe any parent?). > > If I remove the use of parent_in_old_cols entirely, the merge looks > right, but the "collapsing" one is broken (and t4214 fails). > > By the way, a useful trick I stumbled on to look at the coloring across > many such merges: > > git log --graph --format=%h --color | grep -A2 -e - | less -S > > It looks like every octopus in git.git is colored wrong (because they're > the non-collapsing type).
Thanks for analysing further. I wonder if new tests added by Denton's BUG/PATCH series cover both kinds? It would be good to make sure that any "fix" corrects known-broken cases while keeping the working cases still working. Thanks.
