> This still wouldn't be an error condition though, especially in terms
> of how "git config" should treat it.
The man page says:
"This command will fail with non-zero status upon error."
Of course, one might claim that this does not mean the truth of the
reverse condition, i.e. that when the command returns 1 that is
necessarily an error, but I would leave that avenue of thinking to
philosophers. Besides that, it is common practice in *nix OSs to
consider a return != 0 as an error.
> It should be up to the consumer
> of the information to display, or not, any error or diagnostics that
> don't result from either a bad request (your first case) or a
> malformed configuration file. This fits with the callback nature of
> how the config file is parsed by builtin tools. The exit code from
> "git config" with a missing key is enough for the consumer to make
> this decision.
A well-behaved, user-friendly program, when detects an error tells the
user what went wrong.
How can otherwise the user tell a corrupted configuration file from a
Of course, is is possible to provide a git-config that simply returns
0 when it has got the key and 1 when it does not, without issuing any
error message, but the current one is not like that, it is a middle
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html