On Tue, Mar 20, 2018 at 09:58:14AM +0000, Phillip Wood wrote: > > Are you using any exotic filters for your pager? If you use "git > > --no-pager" does the problem persist? > > Hi Peff, thanks for taking the time to check this, I had forgotten about > the pager. I'm using diff-highlight and it seems that is causing the > problems. Heh. Lucky guess. Unsurprisingly, I use diff-highlight, too. But I did not see it because I never bothered to upgrade my personal copy of the script, which has been working for me for ages, to the one in contrib/. But indeed, I can easily reproduce the problem with that version of the script. Here's a pretty minimal reproduction: -- >8 -- cat >bad <<\EOF * commit whatever | other stuff irrelevant | | diff --git a/foo b/foo | --- a/foo | --- b/foo | @@ -100,6 +100,9 | some | context | lines | +some | +new | +lines | -context line with a leading minus | and other | context EOF contrib/diff-highlight/diff-highlight <bad -- 8< -- which produce: ... | -context line with a leading minus | +some | +new | +lines ... The issue bisects to 7e4ffb4c17 (diff-highlight: add support for --graph output, 2016-08-29). I think the problem is the "\s+" at the end of the $GRAPH regex, which soaks up the space for the context, and accidentally treats the "-" line as a preimage removal. But just switching that to "\s" doesn't quite work. We may have an arbitrary number of spaces between the graph ascii-art and the diff. E.g., if you have a commit at the base of a branch (the test in contrib/diff-highlight shows this case). So I think you'd have to record the indent of the previous hunk header, and then make sure that the indent matched that. But even there, I think we're subject to false positives if a commit message contains a hunk header (it's indented an extra 4 characters, but we'd accidentally soak that up thinking it was graph indentation). To make it bullet-proof, I think we'd have to actually parse the graph structure, finding a "*" line and then accepting only an indent that matched it. -Peff
