Junio C Hamano <gits...@pobox.com> writes:
> ... 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).
The last case should end more like this:
..., it should stay, but why are you writing a comment that
is not specific to this section _inside_ the section in the
first place???
Another case we have to worry about, if we were to remove an empty
section header is this case:
# 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 the state of my primary working area as-is
mirror
# Traditional "canonical" one
[remote "korg"]
url = k.org:/pub/scm/user/git
If I were to retire "github" account, removing the section while
keeping the comments would be confusing (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.
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 the state of my primary 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.
--
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
