[BUG] git config does not reuse section name

When I repeat the following n times

    $ git config color.ui always
    $ git config --unset color.ui

it ends up the section name [color] n times in the .git/config file.

like this for n=4:

    [color]
    [color]
    [color]
    [color]

Using git version 1.6.5.3 (I don't know whether this is already fixed in in later versions)

Yakup

Yakup Akbay <yakbay@ubicom.com> writes:

If I recall correctly, this hasn't been even noticed/reported/recognized as an issue, ever since the "git repo-config" was introduced (which later was renamed to "git config"). Dscho, do you remember details?

Heya,

On Mon, Dec 7, 2009 at 21:04, Junio C Hamano <gitster@pobox.com> wrote:

I poked Dscho about it at some point.

He told me that the 'git config' code is so horrible that it's nigh-impossible to change the behavior, hence why he didn't do it :P.

Sverre Rabbelier <srabbelier@gmail.com> writes:

Hmm, sad.  I thought it was mostly his code...

Hi,

On Mon, 7 Dec 2009, Sverre Rabbelier wrote:

Actually, I said something about the most obvious route being to re-use git_config() and that this approach had its limitations.

I also said that I earned (probably rightfully) a reputation of lousy code with Junio, which makes me think that I probably should refrain from ever contributing code to Git again.

Ciao, Dscho

Hi,

On Mon, 7 Dec 2009, Junio C Hamano wrote:

IIRC, due to technical limitations, the config machinery only recognizes sections if there is at least _one_ entry in them. This is because git_config() is used to determine (from the current file position) where the section begins.

And likewise, due to those technical limitations, the section header is not removed when the last entry in the section is removed (this was because I did not want to change the location of the section, but due to the mentioned limitation, that did not work out).

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Ah, the reading side should be able to get by with that parsing logic, as an empty section is totally ignorable anyway. And the parser for the writing side reuses that logic. Asking for removal code to notice the empty section and remove it needs a bit of restructuring of the parsing logic as currently it doesn't even see an empty section.

Thanks---the explanation makes sense (I am not saying "it justifies it"; I only mean "it explains why the code behaves like that very well").

I think we have kept the original parsing structure since repo-config added the write support, and "fixing" the issue is not that urgent, but it would be nice to get it fixed. Perhaps somebody can find some time over the upcoming holidays ;-)