Re: git-grep's "-z" option misbehaves in subdirectory

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2020, 20:07 UTC
Message-ID: <xmqq1ronyz1s.fsf@gitster.c.googlers.com>
In-Reply-To: <CAHd-oW4NK3E2umq9OXXW9TUyLKQwWN4R-b1KKK117tWPc=K7aw@mail.gmail.com>

Matheus Tavares Bernardino <matheus.bernardino@usp.br> writes:

Show 14 quoted lines

> 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 ...

Let me lift the need for speculation ;-) It was a simple oversight when the documentation was writte, and those "add relative with quoting" were bugs that not many people thought of testing with -z output mode. It is unfortunate, but it happens that things fall into cracks without anybody noticing X-<.

The reason why we quote paths in output from various commands without -z is to make them machine parseable; there is no reason to quote if \0 delimiting is used as no paths contain NUL byte in 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".

This is the only sensible way forward, I would think.