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:

  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:

  foo = bar
  # This isn't necessary anymore because...
  # xyzzy = false

or even:

  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.

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

Reply via email to