Re: [PATCHv2] git-config: Parse config files leniently
From: Michael J Gruber <hidden>
Date: 2016-06-15 22:47:21
Junio C Hamano venit, vidit, dixit 03.09.2009 09:00:
Michael J Gruber [off-list ref] writes:quoted
Currently, git config dies as soon as there is a parsing error. This is especially unfortunate in case a user tries to correct config mistakes using git config -e. Instead, issue a warning only and treat the rest of the line as a comment (ignore it). This benefits not only git config -e users but also everyone else.This changes the behaviour enough to break t3200-branch.sh, test #52. The test stuffs an invalid (but not syntactically incorrect) value used by "git branch" in the configuration and tries to make sure that "git branch" diagnoses the breakage, but it does not fail anymore with your patch. There are probably other breakages as well (e.g. t5304-prune.sh, test #5) but if you trace "git branch" under the debugger in the trash directory left after running t3200 with -i, it should be pretty obvious that your patch is utterly bogus. get_value() can return negative result after diagnosing a semantic problem with the value, and that is different from a syntax error that you would try to recover and continue, pretending you can ignore the remainder of the line as if it is a comment. Why was I CC'ed, if the patch wasn't even self tested?
Because - not CC'ing you would have meant culling you from the existing CC, - we've discussed v1 of this patch before, - I asked in this patch (v2) whether to go for an alternative. Since "git config -e" for broken config is not my itch at all, but the reporter's, I'll stop my efforts after this response. Michael