Hi Ben > 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 missing key? 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 way solution. -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html