On Sun, Aug 14, 2016 at 09:29:27PM -0400, Eli Barzilay wrote:
> Looks like there's a problem with setting a config with an empty
> section, making it create a new section. The result is:
>
> $ git --version
> git version 2.9.2
> $ git init
> Initialized empty Git repository in /home/eli/t/.git/
> $ t() { git config x.y x; git config --unset x.y; }
> $ t;t;t
> $ grep -c '\[x\]' .git/config
> 3
> $ git config x.z x
> $ t;t;t
> $ git config x.z x # adds another [x], but leaves it populated
> $ t;t;t;t;t;t;t;t
> $ grep -c '\[x\]' .git/config
> 4
Yep. This is a very old and well-known bug. IIRC, the problem is that
config updates use the regular callback-parser, so they see only the
config keys themselves. Empty section headers never trigger them.
Fixing it would require rewriting the config-update code.
And implicit in your test is the other bug, which is that deleting the
last key in a section leaves the empty header. I think it's related to
the same issue.
Patches welcome, of course.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
