Re: [PATCH/RFC] git-grep: correct exit code with --quiet and -L

2 messages, 2 authors, 2017-08-15 · open the first message on its own page

Re: [PATCH/RFC] git-grep: correct exit code with --quiet and -L

From: Junio C Hamano <hidden>
Date: 2017-08-15 22:24:44

Anthony Sottile [off-list ref] writes:
Ah yes, I didn't intend to include the first hunk (forgot to amend it
out when formatting the patch).

I think git's exit codes for -L actually make more sense than the GNU
exit codes (especially when comparing with `grep` vs `grep -v`) --
that is, produce `0` when the search is successful (producing
*something* on stdout) and `1` when the search fails.

Shall I create a new mail with the adjusted patch as suggested above?
I do not mind seeing an updated patch that does not change the exit
status (as you seem to like what we have currently that contradicts
what GNU grep does) but makes it consistent between "--quiet" and
"--no-quiet".  But I would not be surprised if people seeing this
exchange from the sideline are already working on fixing the exit
status and also making sure that the fixed code would produce the
same corrected exit status with or without "--quiet", so an updated
patch from you will likely conflict with their effort.

So if I were you, I'd wait to see what other people would say about
the actual exit codes we give when "git grep -L" is run without the
"--quiet" option, and if they are also happy with the current exit
code, then send in an updated patch.

Thanks.

Re: [PATCH/RFC] git-grep: correct exit code with --quiet and -L

From: Anthony Sottile <hidden>
Date: 2017-08-15 22:43:57

Sounds good, I'll wait.

I've also created a mailing list entry on the gnu grep mailing list as
I believe the current exit status for --files-without-match is
inconsistent:

http://lists.gnu.org/archive/html/bug-grep/2017-08/msg00010.html

Anthony

On Tue, Aug 15, 2017 at 3:24 PM, Junio C Hamano [off-list ref] wrote:
Anthony Sottile [off-list ref] writes:
quoted
Ah yes, I didn't intend to include the first hunk (forgot to amend it
out when formatting the patch).

I think git's exit codes for -L actually make more sense than the GNU
exit codes (especially when comparing with `grep` vs `grep -v`) --
that is, produce `0` when the search is successful (producing
*something* on stdout) and `1` when the search fails.

Shall I create a new mail with the adjusted patch as suggested above?
I do not mind seeing an updated patch that does not change the exit
status (as you seem to like what we have currently that contradicts
what GNU grep does) but makes it consistent between "--quiet" and
"--no-quiet".  But I would not be surprised if people seeing this
exchange from the sideline are already working on fixing the exit
status and also making sure that the fixed code would produce the
same corrected exit status with or without "--quiet", so an updated
patch from you will likely conflict with their effort.

So if I were you, I'd wait to see what other people would say about
the actual exit codes we give when "git grep -L" is run without the
"--quiet" option, and if they are also happy with the current exit
code, then send in an updated patch.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help