🐛Handle diff.submodule log

[fdcds]

It appears that delta has some trouble finding the end of a hunk:

--- a   2019-11-27 12:06:18.472973416 +0100
+++ b   2019-11-27 12:06:23.992967043 +0100
@@ -1,7 +1,7 @@
 x
 y
 z
-a
+b
 z
 y
 x
Submodule x/y/z contains untracked content

Is displayed (roughly) as:

a
---------------------------------------
-----|
 ... |
-----|
1
 x
 y
 z
-a
+b
 z
 y
 x
 ubmodule x/y/z contains untracked content

Note how "Submodule"'s first character gets removed by delta.

Using delta 0.0.14.

[fdcds]

Proposal how to fix this: A hunk in unified diff starts with ^@@. That line already contains all the information you need: The first number is the line the hunk starts on (irrelevant for you) and the second number (after the comma) is the size of the hunk before (-) / after (+) the changes. So from there you count the number of lines starting with (keep line), - (remove) and + (add). Then num_keep + num_remove == hunk_size_before and num_keep + num_add - num_remove == hunk_size_after.

So your state machine can be quite dump: You go into a "hunk state" once you reach ^@@ and then read lines until both equations above hold, at which point you have reached the end of the hunk. Then you can do the highlighting of that hunk, output it, leave "hunk state" and search for the next hunk.

For robustness, you should probably also stop when you find a line that does not match ^[ +-], independently of how many lines you already read (reason unknown, but you should not care why).

[fdcds]

Somehow this seems to not have worked. With git config --global diff.submodule log git diff outputs:

[...]
Submodule a/b/c a12bc..de34f:
  > Commit 2 Message
  > Commit 1 Message
[...]

With git config --global core.pager "delta --dark" I get following output:

[...]
Submodule a/b/c a12bc..de34f:
----
[...]

I.e. the changes to the commits are not displayed any longer.

It thus appears that delta still mangles lines outside the changed files, in this case also the indented changes to the submodule's commits, which is in "normal diff" format (>/<).

[dandavison]

Hi @fdcds Sorry this second bug has taken so long to fix. I can reproduce it. I notice that a workaround would be to use --file-style plain or --color-only, but I agree another fix to the parsing logic is still needed here.

[dandavison]

Looks like this has been fixed in the intervening 5 years; I haven't bisected to find out where yet. Thanks very much @fdcds. A PR doing something in the direction of your very nice suggestion was just merged (#1787) which brought this issue to mind.