Junio C Hamano venit, vidit, dixit 03.09.2009 09:00: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> 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 -- 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