🐛 Incorrect output when grepping in a branch with "/" and "-" in the name

[cffswb]

Context

OS: Linux
Delta revision: 427c9aa

Description

Tested in delta repository.

Run git grep alone:
$ GIT_CONFIG_GLOBAL=/dev/null git grep theme origin/gh-pages

Run git grep + delta:
$ GIT_CONFIG_GLOBAL=/dev/null git -c pager.grep='delta --no-gitconfig' grep theme origin/gh-pages

The gh-pageses become gh:pageses, and the themes aren't highlighted.

[dandavison]

Thanks @cffswb, will look into this.

By the way, until this is fixed, I just want to mention that piping rg --json into delta should never have parsing bugs (since delta receives a JSON format rather than having to parse grep output, which can't be parsed unambiguously, although I don't think we should be confusing an internal - character in a file name if that's what's happening here)

[mvf]

This seems to also affect paths whose element just above the file has a - in it. Here's a shot of git grep hostmakedepends from the root of https://www.github.com/void-linux/void-packages. cyrus-sasl and d-feet are mangled:

The same command from the srcpkgs directory leaves d-feet intact, but the highlighting isn't applied anymore:

This seems to happen when the path element with the - comes first and only has a single character before the first -.

[joshtriplett]

@mvf Confirmed. Here's a reproducible example of that:

• Clone https://github.com/rust-lang/libz-sys
• git grep -e '-arch'

There are hits in src/zlib/configure and src/zlib-ng/configure, but notice that the latter gets printed as src/zlib:ng/configure:

[dandavison]

Hi all, currently the best answer here is to use rg --json to avoid any parse errors. Fundamentally the issue here is that traditional grep output is not unambiguously parseable. It would be nice if someone added JSON output to git grep. Copying from the other dup issues #1631 and #1259:

The delta manual contains an entry addressing this:

If you don't need special features of git grep, then for best results pipe rg --json output to delta: this avoids parsing ambiguities that are inevitable with the output of git grep and grep.

See the ~500 lines of unit tests here: https://github.com/dandavison/delta/blob/main/src/handlers/grep.rs#L653-L1177. If someone can improve the parsing while keeping all those tests passing (and hopefully adding a test for what you're fixing) that would be fantastic.

I'm going to close this since I have personally taken a fairly large stab at it and also implemented rg --json support for a fully robust solution.

[joshtriplett]

@dandavison One idea for handling this unambiguously (asking first to find out if this would be an acceptable solution):

git grep emits color sequences, one of which is wrapped around the filename. delta could parse those color sequences and use them to determine when the filename ends, unambiguously. If that works, then the recommended delta configuration could include turning on color for grep. (If delta doesn't see the starting sequence at the start of the line, it could still fall back to today's ambiguous parsing.)

[dandavison]

@joshtriplett I think that's a good idea! I had thought that git would refuse to deliver the color escape codes when sending output to its pager, but it looks like it does, as can be verified with

GIT_PAGER='bat --plain -A' git grep foo

the recommended delta configuration could include turning on color for grep

It seems that git grep has color enabled by default, right?

[joshtriplett]

@dandavison Yes, grep and other commands use color by default unless disabled. However, people can customize the colors/styles. So, delta might want to document what does and doesn't work.

[joshtriplett]

@dandavison Fixed: #1634