# [BUG] git config does not reuse section name 7 messages from 2009-12-07 to 2009-12-08. Participants: Yakup Akbay, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin. Thread: https://gitlist.dev/t/21893 ## Yakup Akbay, 2009-12-07 17:06 Subject: [BUG] git config does not reuse section name Message-ID: <4B1D360B.4070203@ubicom.com> URL: https://gitlist.dev/e/4B1D360B.4070203%40ubicom.com ``` 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 ``` ## Junio C Hamano, 2009-12-07 20:04 Subject: Re: [BUG] git config does not reuse section name Message-ID: <7vy6le35zv.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy6le35zv.fsf%40alter.siamese.dyndns.org In-Reply-To: <4B1D360B.4070203@ubicom.com> ``` Yakup Akbay writes: > 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) 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? ``` ## Sverre Rabbelier, 2009-12-07 20:23 Subject: Re: [BUG] git config does not reuse section name Message-ID: URL: https://gitlist.dev/e/fabb9a1e0912071223l21c70e2ax9b0e3c9976ae9d7%40mail.gmail.com In-Reply-To: <7vy6le35zv.fsf@alter.siamese.dyndns.org> ``` Heya, On Mon, Dec 7, 2009 at 21:04, Junio C Hamano wrote: > 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"). I poked Dscho about it at some point. > Dscho, do you remember details? 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. -- Cheers, Sverre Rabbelier ``` ## Junio C Hamano, 2009-12-07 20:54 Subject: Re: [BUG] git config does not reuse section name Message-ID: <7vfx7m1p4a.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vfx7m1p4a.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Sverre Rabbelier writes: > On Mon, Dec 7, 2009 at 21:04, Junio C Hamano wrote: >> 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"). > > I poked Dscho about it at some point. > >> Dscho, do you remember details? > > 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. Hmm, sad. I thought it was mostly his code... ``` ## Johannes Schindelin, 2009-12-08 02:01 Subject: Re: [BUG] git config does not reuse section name Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0912080258010.4985%40pacific.mpi-cbg.de In-Reply-To: <7vy6le35zv.fsf@alter.siamese.dyndns.org> ``` Hi, On Mon, 7 Dec 2009, Junio C Hamano wrote: > Yakup Akbay writes: > > > 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) > > 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? 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, 2009-12-08 02:05 Subject: Re: [BUG] git config does not reuse section name Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0912080304290.4985%40pacific.mpi-cbg.de In-Reply-To: ``` Hi, On Mon, 7 Dec 2009, Sverre Rabbelier wrote: > On Mon, Dec 7, 2009 at 21:04, Junio C Hamano wrote: > > 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"). > > I poked Dscho about it at some point. > > > Dscho, do you remember details? > > 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. 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 ``` ## Junio C Hamano, 2009-12-08 03:27 Subject: Re: [BUG] git config does not reuse section name Message-ID: <7vy6lep2ly.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy6lep2ly.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Johannes Schindelin writes: > 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. 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 ;-) ```