Empty config sections are neither deleted nor reused

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

Jonas Bernoulli <jonas@bernoul.li> writes:

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

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

Jonas Bernoulli <jonas@bernoul.li> 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.

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 <Matthieu.Moy@grenoble-inp.fr> writes:

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

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

That's how I read it too ;-)

Apparently my reply left more room for interpretation.