Re: Minor bug: git config ignores empty sections
- From
Jeff King <peff@peff.net>
- Date
- Aug 15, 2016, 18:55 UTC
- Message-ID
- <20160815185500.htgrz3t2wkztg4ww@sigill.intra.peff.net>
- In-Reply-To
- <xmqqh9alhoor.fsf@gitster.mtv.corp.google.com>
On Mon, Aug 15, 2016 at 11:28:20AM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> writes: > > > On Mon, Aug 15, 2016 at 07:34:50PM +0200, Andreas Schwab wrote: > > > >> On Aug 15 2016, Jeff King <peff@peff.net> wrote: > >> > >> > 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. > >> > >> Indiscriminately removing empty section headers may break comments that > >> have been put there on purpose. > > > > I know, but we do not even do so discriminately. > > I notice that we have thought about all the issues when we last > discussed it in 2013. Refining a message from the earlier thread, > as it illustrates tricky cases in which we have to be careful.
Thanks for digging up the threads that I was too lazy to find.
I agree with most everything here, though I would be happy if somebody even wrote a patch to handle the "easy" cases.
> So a comment outside [section "name"] is tricky; it needs some > mechanism (or convention) to tell us if it is about the particular > section, or it is about the location in the configuration file.
Keep in mind that even "outside" is hard, because sections do not explicitly close.
So in:
[core] foo = bar
# here are my remotes
[remote "github"] url = ...
How do we know that the comment is "outside" and not part of [core]?
We can perhaps guess so because there are no keys after it in the section, though there are some special cases, like:
[core] foo = bar # This isn't necessary anymore because... # xyzzy = false
or even:
[core] foo = bar # needed because of xyzzy
You can probably make reasonable cases based on heuristics around newlines, but that is even further into "convention" territory.
-Peff