git v2.37 interactive --patch: error: could not parse colored hunk header

[OJFord]

I haven't had a chance to look much into this, but this seemed to start with git v2.37.0:

$git init
$git config interactive.diffFilter 'diff-so-fancy --patch'
$touch empty
$git add empty
$echo not > empty
$git add -p empty
error: could not parse colored hunk header '?[1;35m?[1;35m@ empty:1 @?[1m?[0m'

[scottchiefbaker]

I don't have git v.2.37.0 installed so I'm flying blind here... The phrase "could not parse" is not in d-s-f anywhere, so I'm sort of confused. What is generating that error? Git itself?

My first guess would be that it's some new ANSI color sequence we just don't understand yet. Can you generate a "raw" file and recreate the problem?

[OJFord]

I assume it's from git yes, trying to parse the output from diff-so-fancy --patch.

The above diff with no interactive.diffFilter:

diff --git a/empty b/empty
index e69de29bb..2efad47f3 100644
--- a/empty
+++ b/empty
@@ -0,0 +1 @@
+not

and that file then through diff-so-fancy --patch:

[0m[1;33m────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[0m
[1;33mmodified: empty
[1;33m────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────[0m
[1;35m@ empty:1 @[1m[0m
[1;32mnot[0m

[scottchiefbaker]

Hmmmmmm that looks like a pretty vanilla diff ANSI color sequence to me. Maybe Git made some changes that look for a VERY specific sequence?

[OJFord]

May be a git bug of course. Delta facing the same issue: dandavison/delta/issues/1114

Some recent changes (new in 2.37) https://github.com/git/git/commits/master/add-patch.c,

"git add -p" rewritten in C regressed hunk splitting in some cases,

sounds, err, maybe related.. but I can't actually find what 'rewritten in C' refers to, add-patch.c seems to have been there years.

[scottchiefbaker]

Oh nice... Good find!

[malsyned]

This work-around worked for me: git config --global add.interactive.useBuiltin false Obviously that's not ideal long-term since it disables the new faster git add -p implementation.

[malsyned]

sounds, err, maybe related.. but I can't actually find what 'rewritten in C' refers to, add-patch.c seems to have been there years.

The configuration flag add.interactive.useBuiltin got a new default value of true in 2.37. The implementation has existed for a while but has been considered experimental and disabled by default until now.

[OJFord]

Thanks!

[phil-blain]

I would say it is a Git regression, and should be reported to the Git mailing list: http://git-scm.com/community.

[shmup]

This work-around worked for me: git config --global add.interactive.useBuiltin false Obviously that's not ideal long-term since it disables the new faster git add -p implementation.

Hm, enabling that presents me with:

$ git add -p

fatal: mismatched output from interactive.diffFilter
hint: Your filter must maintain a one-to-one correspondence
hint: between its input and output lines.

Specifically setting:

[add "interactive"]
	useBuiltin = false
[interactive]
	diffFilter = diff-so-fancy --patch

[albandiguer]

The solution from Malsyned also works with nix & home manager.

programs.git = {
  extraConfig = {
    add.interactive.useBuiltin = false;
  }
}

[phil-blain]

I would say it is a Git regression, and should be reported to the Git mailing list: http://git-scm.com/community.

Reported here: https://lore.kernel.org/git/[email protected]/T/#u

[phil-blain]

Fixed in Git 2.38 which came out today: https://github.com/git/git/blob/3dcec76d9df911ed8321007b1d197c1a206dc164/Documentation/RelNotes/2.38.0.txt#L353-L356

[scottchiefbaker]

@phil-blain good catch!

[will]

@phil-blain thanks for taking the time to post here, this is great news!