Re: [RFC PATCH] Make rev-parse -q and --is-* quiet

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2020, 18:18 UTC
Message-ID: <xmqqa74kce4t.fsf@gitster.c.googlers.com>
In-Reply-To: <20200313174755.GA549554@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> I'm not sure if returning a single is_set makes sense, though. It
> effectively becomes an OR, and you wouldn't know which flag triggered
> it. It would make more sense to me for the invocation above to simply be
> an error, reminding the caller that they need to handle it more
> carefully.
>
> We _could_ encode each value into the exit code (e.g., set bit 1 if the
> first condition was true, and so on). But checking that becomes as much
> hassle as reading stdout, so there's little value.

None of the above excites me. I do not think it makes much sense to combine -q with --is-* for the reasons you stated already (i.e. the caller cannot tell between "failure" and "false") in the first place, but if we must do this:

 - reserve 0 (true) and 1 (false) for successful exit and use 2 (or
   above) for other failures;

 - when --quiet is in use, make --is-* mutually exclusive and die
   when more than one of them is given.  I think any of the --is-*,
   when used with --quiet, should also be an error if there are revs
   on the command line (e.g. "git rev-parse --is-inside-git-dir
   HEAD" is OK, but not with "--quiet").

is the minimum that makes me feel that we have semi-reasonable behaviour that can be explained to end users.