Re: [PATCH] config: fix case sensitive subsection names on writing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux