git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Stefan Beller <sbeller@google.com>
Cc: Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>,
	Brandon Williams <bmwill@google.com>, peff <peff@google.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] config: fix case sensitive subsection names on writing
Date: Sat, 28 Jul 2018 06:53:51 -0400	[thread overview]
Message-ID: <20180728105351.GA13283@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGZ79ka2yRv5+EaBoHx_TWdM1Qgt9F7YZiW=X35MyOehfcdQBg@mail.gmail.com>

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

  reply	other threads:[~2018-07-28 10:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-27 20:51 [PATCH] config: fix case sensitive subsection names on writing Stefan Beller
2018-07-27 21:21 ` Brandon Williams
2018-07-27 21:39   ` Junio C Hamano
2018-07-27 23:35     ` Stefan Beller
2018-07-27 23:36       ` Stefan Beller
2018-07-27 23:37         ` Stefan Beller
2018-07-28  1:01         ` Junio C Hamano
2018-07-28  3:52           ` Stefan Beller
2018-07-28 10:53             ` Jeff King [this message]
2018-07-28  1:37         ` Junio C Hamano
2018-07-30 12:49           ` Johannes Schindelin
2018-07-30 23:04             ` [PATCH 0/3] " Stefan Beller
2018-07-30 23:04               ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2018-07-30 23:04               ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-07-31 20:16                 ` Junio C Hamano
2018-07-30 23:04               ` [PATCH 3/3] config: treat section case insensitive in store_aux_event Stefan Beller
2018-07-31 15:16               ` [PATCH 0/3] config: fix case sensitive subsection names on writing Junio C Hamano
2018-08-01 19:34                 ` [PATCH 0/3] sb/config-write-fix done without robbing Peter Stefan Beller
2018-08-01 19:34                   ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2018-08-01 19:34                   ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-01 21:01                     ` Ramsay Jones
2018-08-01 22:26                       ` Junio C Hamano
2018-08-01 22:51                     ` Junio C Hamano
2018-08-03  0:30                       ` Stefan Beller
2018-08-03 15:51                         ` Junio C Hamano
2018-08-01 19:34                   ` [PATCH 3/3] git-config: document accidental multi-line setting in deprecated syntax Stefan Beller
2018-08-01 19:58                   ` [PATCH 0/3] sb/config-write-fix done without robbing Peter Eric Sunshine
2018-08-02 19:49                   ` Junio C Hamano
2018-08-03  0:34                   ` [PATCH 0/3] Reroll of sb/config-write-fix Stefan Beller
2018-08-03  0:34                     ` [PATCH 1/3] t1300: document current behavior of setting options Stefan Beller
2018-08-03  0:34                     ` [PATCH 2/3] config: fix case sensitive subsection names on writing Stefan Beller
2018-08-03  0:34                     ` [PATCH 3/3] git-config: document accidental multi-line setting in deprecated syntax Stefan Beller
2018-07-27 21:37 ` [PATCH] config: fix case sensitive subsection names on writing Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180728105351.GA13283@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@google.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).