On Mon, Aug 15, 2016 at 11:28:20AM -0700, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Mon, Aug 15, 2016 at 07:34:50PM +0200, Andreas Schwab wrote: > > > >> On Aug 15 2016, Jeff King <p...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
