Thread (1 message) 1 message, 1 author, 2019-10-03

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

From: Junio C Hamano <hidden>
Date: 2019-10-03 22:16:44

Jeff King [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help