Re: Minor bug: git config ignores empty sections

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> On Mon, Aug 15, 2016 at 07:34:50PM +0200, Andreas Schwab wrote:
>
>> On Aug 15 2016, Jeff King <peff@xxxxxxxx> 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.

If we were to remove the section header at this point, we should
be removing the comment two out of three cases.

 - if it is about section.key, it should go when section.key goes.
 - if it is about section, it should go when section goes.
 - if it is a more generic comment about this configuration file,
   it should stay.

A configuration file may have something like this:

        # Now, let's list all the remotes I interact with.

        # This is where I push all the separate topics.
        [remote "github"]
                # fetch like everybody else without auth
                url = git://github.com/user/git
                # push with auth
                pushURL = github.com:user/git
                # publish my working area as-is
                mirror

        # Traditional "canonical" one
        [remote "korg"]
                url = k.org:/pub/scm/user/git

If I were to retire the "github" account, removing the entire
[remote "github"] section while keeping the comments before that
section would be confusing, which would end up with:

        # Now, let's list all the remotes I interact with.

        # This is where I push all the separate topics.

        # Traditional "canonical" one
        [remote "korg"]
                url = k.org:/pub/scm/user/git

because I do not push all the separate topics to korg.

Removing the section while removing the comments that pertain to the
section is impossible; "Now, let's list all the remotes" should
stay, "This is where I push" should go.

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.

Removing only the keys and keeping the skelton around would give us:

        # Now, let's list all the remotes I interact with.
        # This is where I push all the separate topics.
        [remote "github"]
                # fetch like everybody else without auth
                # push with auth
                # publish my working area as-is

        # Traditional "canonical" one
        [remote "korg"]
                url = k.org:/pub/scm/user/git

which is still confusing, but at least the confusion is not spread
to adjacent sections.  What we could do easily without understanding
natural languages is to remove comments inside [section "name"], but
it still depends on a convention that such a per-key comment comes
before the key, not after, i.e.

        # This is where I push all the separate topics.
        [remote "github"]
                # fetch like everybody else without auth
                ...
                # publish my working area as-is
                mirror
		# note that mirror may push out outside tags/ and heads/

	# Traditional "canonical" one
	[remote "korg"]

We could also take hints from the indentation level, but now we are
deep into the "convention" territory once we start doing that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]