On Fri, Jul 27, 2018 at 08:52:59PM -0700, Stefan Beller wrote: > > > + for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r" > > > + do > > > + cp testConfig testConfig_actual && > > > + git config -f testConfig_actual v.a.r value2 && > > > + test_cmp testConfig_expect testConfig_actual > > > + done > > > +' > > > > I think you meant to use "$key" when setting the variable to value2. > > > > When the test_cmp fails with "v.a.r" but later succeeds and most > > importantly succeeds with "V.a.r" (i.e. the last one), wouldn't the > > whole thing suceed? I think the common trick people use is to end > > the last one with "|| return 1" in a loop inside test_expect_success. > > Hah, of course this patch is not as easy. > > The problem is in git_parse_source (config.c, line 755) when we call > get_base_var it normalizes both styles, (and lower cases the dot style). > > So in case of dot style, the strncasecmp is correct, but for the new > extended style we need to strncmp. > > So this is correct for extended but not any more for the former dot style. Hmm, it looks like this has always been broken. Before your patch (but after v2.18.0), running "git config v.A.r value2" writes: [V.A] r = value1 r = value2 which is obviously broken (we decided it was the right section, but didn't match the variables, leading to a weird duplicate). After your patch we write: [V.A] r = value1 [v "A"] r = value2 I.e., we do not consider them the same value at all. But that's actually what happened before v2.18, too. I think you could almost justify that behavior as "The section.subsection syntax is deprecated, so we match it case-insensitively on reading but not on writing; since we never write such sections ourselves, you are on your own for modifying such entries if you choose to write them manually". I dunno. Maybe that is too harsh. But this syntax has been deprecated for 7 years, and nobody has noticed the bug until now (when _still_ nobody wants to use it, but rather we're poking at it as "gee, I wonder if this even works"). > I wonder if we want to either (a) add another CONFIG_EVENT_SECTION > that indicates the difference between the two, or have a flag in 'cf' that > tells us what kind of section style we have, such that we can check > appropriately for the case. I'd think that the parse_event_data could carry type-specific information. But... > Or we could encode it in the 'cf->var' value to distinguish the old > and new style. Even if we fix the section-matching here, I suspect that would just trigger a separate bug later when we match the full key (so we might add to the correct section, but we would not correctly replace an existing key). To fix that, the information does need to be carried for the whole lifetime of cf->var, not just during the header event. -Peff
