From: Junio C Hamano <gitster@pobox.com>
To: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
Cc: git <git@vger.kernel.org>, "Greg Hurrell" <greg@hurrell.net>,
"Andreas Heiduk" <asheiduk@gmail.com>,
"René Scharfe" <l.s.r@web.de>
Subject: Re: git-grep's "-z" option misbehaves in subdirectory
Date: Thu, 16 Apr 2020 13:07:43 -0700 [thread overview]
Message-ID: <xmqq1ronyz1s.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAHd-oW4NK3E2umq9OXXW9TUyLKQwWN4R-b1KKK117tWPc=K7aw@mail.gmail.com> (Matheus Tavares Bernardino's message of "Thu, 16 Apr 2020 15:59:12 -0300")
Matheus Tavares Bernardino <matheus.bernardino@usp.br> writes:
> 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.
next prev parent reply other threads:[~2020-04-16 20:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 21:55 git-grep's "-z" option misbehaves in subdirectory Greg Hurrell
2020-04-13 23:33 ` Junio C Hamano
2020-04-14 7:42 ` Matheus Tavares
2020-04-16 18:59 ` git-grep's "-z" option misbehaves in subdirectory Matheus Tavares Bernardino
2020-04-16 20:07 ` Junio C Hamano [this message]
2020-04-17 6:04 ` [PATCH] grep: follow conventions for printing paths w/ unusual chars Matheus Tavares
2020-04-17 6:45 ` Junio C Hamano
2020-04-17 21:19 ` Matheus Tavares Bernardino
2020-04-17 21:35 ` Junio C Hamano
2020-04-18 13:13 ` Johannes Schindelin
2020-04-18 14:56 ` Johannes Schindelin
2020-04-19 6:27 ` Matheus Tavares Bernardino
2020-04-19 6:33 ` [PATCH v2] " Matheus Tavares
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1ronyz1s.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=asheiduk@gmail.com \
--cc=git@vger.kernel.org \
--cc=greg@hurrell.net \
--cc=l.s.r@web.de \
--cc=matheus.bernardino@usp.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.