Subject: Re: [BUG/PATCH 0/5] t4214: cleanup and demonstrate graph bug

From: Junio C Hamano <[email-masked]>
Date: Fri, 04 Oct 2019 07:16:34 +0900

Jeff King <[email-masked]> 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.