Jeff King <peff@xxxxxxxx> writes: > 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.
