[Oops, I messed up the headers in my reply, so I'm not sure if the
message was properly delivered. I'm replying again, just in case.]
On Mon, Apr 13, 2020 at 6:57 PM Greg Hurrell <greg@xxxxxxxxxxx> wrote:
>
> It seems that `git-grep -lz` behaves differently depending on whether
> it is inside a subdirectory:
[...]
> $ git grep -lz content
> an "example".txt^@nested/other "example".txt^@
>
> Note that, as expected, the files are NUL-terminated and not wrapped
> in quotes. ("^@" represents NUL byte.)
>
> $ cd nested
> $ git grep -lz content
> "other \"example\".txt"^@
>
> As soon as we move into a subdirectory, files are wrapped in quotes
> and contain escapes, despite the "-z" switch.
Note that, differently from other Git commands, "-z" doesn't affect
quoting/escaping in git-grep. For example, while git-ls-files' man
page says:
-z
\0 line termination on output **and do not quote filenames**.
The git-grep one only says:
-z, --null
Output \0 instead of the character that normally follows a file name.
Indeed, this inconsistency might be a little confusing. The reason for
it may be because "-z" was added in git-grep [1] to mimic the GNU grep
"-Z" flag, which outputs '\0' after file names. In GNU grep, pathnames
are never quoted (regardless of whether or not "-Z" is used). Also
note that, probably due to the same reason, git-grep doesn't obey the
core.quotePath setting (which would make it quote unusual pathnames by
default).
Nevertheless, quoting relative paths but not absolute ones is a bug.
>From what I see, we have two options to fix it:
1. Make git-grep more consistent with other Git commands by always
quoting/escaping unusual pathnames (relative or not), unless "-z" is
given or core.quotePath is set to "false".
2. Keep git-grep compatible with GNU grep, ripgrep and other grepping
tools, removing the quotes/escaping from relative paths as well. In
this case, I think it is also a good idea to add a note about this
behavior in core.quotePath and in git-grep's description of "-z" (as
it may seem confusing to those who are used to the behavior of "-z" in
other Git commands).
In my previous [and possibly corrupted] reply, I included a patch[2]
in the direction of the second option. But thinking about it again,
I'm not really sure which one is the best way forward here. I'd love
to hear what others have to say about it, before sending a more
refined patch.
[1]: See 83caecc, (git grep: Add "-z/--null" option as in GNU's grep.,
2008-10-01)
[2]: https://public-inbox.org/git/20200414074204.677139-1-matheus.bernardino@xxxxxx/
(for some reason, the mail didn't reach lore.kernel.org. Probably my
fault, messing with the headers :/)
