Re: [PATCH 0/9] Assorted fixes for `git config` (including the "empty sections" bug)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 30, 2018, 12:14 UTC
Message-ID: <nycvar.QRO.7.76.6.1803301411480.5026@qfpub.tvgsbejvaqbjf.bet>
In-Reply-To: <CAGZ79ka41uD7A_64kz5oyrhCBci+oXmDGEVc6mHWyQd7d9avAQ@mail.gmail.com>

Hi Stefan,

On Thu, 29 Mar 2018, Stefan Beller wrote:

Show 21 quoted lines

> On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
> 
> > So what is the argument against this extra care to detect comments? Well, if
> > you have something like this:
> >
> >         [section]
> >                 ; Here we comment about the variable called snarf
> >                 snarf = froop
> >
> > and we run `git config --unset section.snarf`, we end up with this config:
> >
> >         [section]
> >                 ; Here we comment about the variable called snarf
> >
> > which obviously does not make sense. However, that is already established
> > behavior for quite a few years, and I do not even try to think of a way how
> > this could be solved.
> 
> By commenting out the key/value pair instead of deleting it.
> It's called --unset, not --delete ;)

That would open the door to new bug reports when a user starts with this concocted config:

	[section]
		# This is a comment about the `key` setting
		key = value

and then does this:

	git config --unset section.key
	git config section.key value
	git config --unset section.key
	git config section.key value
	git config --unset section.key
	git config section.key value

and then ends up with a config like this:

	[section]
		# This is a comment about the `key` setting
		;key = value
		;key = value
		;key = value
		key = value

And note that the comment might be about `value` instead, so reusing a commented-out `key` setting won't fly, either.

I *did* give this problem a couple of minutes of thought before writing my assessment that is quoted above ;-)

Ciao, Dscho