Hi Stefan,
On Thu, 29 Mar 2018, Stefan Beller wrote:
> On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin
> <johannes.schinde...@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
