Empty config sections are neither deleted nor reused

Empty config sections are neither deleted nor reused

[Jonas Bernoulli]

After running

  git init .
  git config foo.bar baz
  git config --unset foo.bar    # 1
  git config foo.bar baz        # 2

.git/config contains

  [core]
          repositoryformatversion = 0
          filemode = true
          bare = false
          logallrefupdates = true
  [foo]
  [foo]
          bar = baz

(1) did not remove the "foo" section when the last contained variable
was unset and (2) did not reuse the empty "foo" section when "foo.bar"
was set again.

I would prefer if unsetting the last variable in a section would cause
the heading of the now empty section would be removed.

But it might also make sense to not remove an empty section and to
instead reuse an empty section.  That would prevent a section from being
moved to eof because it became temporarily empty.  Maybe that was the
intention and Git at some point stopped re-using an empty section?

It could even be argued that it would make sense for empty sections to
be removed *and* reused (in order to "cleanup" old empty sections).

The only possible combination which doesn't make sense is to not remove
an empty section and to also not reuse an empty section - unfortunately
that's what Git currently does.

  Best regards,
  Jonas

Re: Empty config sections are neither deleted nor reused

[Junio C Hamano]

Jonas Bernoulli <jonas@bernoul.li> writes:

> The only possible combination which doesn't make sense is to not remove
> an empty section and to also not reuse an empty section - unfortunately
> that's what Git currently does.

It is not that simple.

The configuration sections can have comments and they are preserved
even when they become empty.  Adding something unrelated will still
make it appear the stale comment applies to it.

If you are interested, start here:

http://thread.gmane.org/gmane.comp.version-control.git/219505/focus=219524

Re: Empty config sections are neither deleted nor reused

[Jonas Bernoulli]

> The configuration sections can have comments and they are preserved
> even when they become empty.  Adding something unrelated will still
> make it appear the stale comment applies to it.

Now that you mention it, I think I have read that before.  Unfortunately
I forgot about it until you reminded me.  I would still prefer if empty
sections were removed and/or reused provided no comment is nearby, but
now that you reminded me why the current behavior is how it is, I can
live with it.

Thanks for the link.

  Jonas

Re: Empty config sections are neither deleted nor reused

[Matthieu Moy]

Jonas Bernoulli <jonas@bernoul.li> writes:

>> The configuration sections can have comments and they are preserved
>> even when they become empty.  Adding something unrelated will still
>> make it appear the stale comment applies to it.
>
> Now that you mention it, I think I have read that before.  Unfortunately
> I forgot about it until you reminded me.  I would still prefer if empty
> sections were removed and/or reused provided no comment is nearby, but
> now that you reminded me why the current behavior is how it is, I can
> live with it.

Junio's explanation must not necessarily be read as "it has to be the
way it is", but more as "getting it right is harder than you think", and
that in turn explains why no one changed the behavior.

Actually, Tanay Abhra's GSoC two years ago included working on this, but
the project had other priorities and the empty sections issue was not
tackled.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Empty config sections are neither deleted nor reused

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio's explanation must not necessarily be read as "it has to be the
> way it is", but more as "getting it right is harder than you think", and
> that in turn explains why no one changed the behavior.

Thanks for clarification.  s/must not necessarily/must not/;

Re: Empty config sections are neither deleted nor reused

[Jonas Bernoulli]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio's explanation must not necessarily be read as "it has to be the
>> way it is", but more as "getting it right is harder than you think", and
>> that in turn explains why no one changed the behavior.
>
> Thanks for clarification.  s/must not necessarily/must not/;

That's how I read it too ;-)

Apparently my reply left more room for interpretation.