Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help