Browse Source
The error handling for git_config is somewhat confusing. We collect errors from running git_config_from_file on the various config files and carefully pass them back up. But the two odd things are: 1. We actually die on most errors in git_config_from_file. In fact, the only error we actually pass back up is if fopen() fails on the file. 2. Most callers of git_config do not check the error return at all, but will continue if git_config reports an error. When the code for "git -c core.foo=bar" was added, it dutifully passed errors up the call stack, only for them to be eventually ignored. This makes it inconsistent with the file-parsing code, which will die when it sees malformed config. And it's somewhat unsafe, because it means an error in parsing a typo like: git -c clean.requireforce=ture clean will continue the command, ignoring the config the user tried to give. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint
![peff@peff.net](/assets/img/avatar_default.png)
![Junio C Hamano](/assets/img/avatar_default.png)
2 changed files with 9 additions and 1 deletions
Loading…
Reference in new issue