Re: [PATCH] Mention that git-branch -M can cause problems for tracking branches

[Junio C Hamano <gitster@pobox.com>]

Jonas Fonseca <fonseca@diku.dk> writes:

> The main reason to "refuse" the removal is that for the general case,
> e.g. when using `git-config --rename-section`, this can potentially lead
> to loss of valuable config settings. This was pointed out by Shawn in
> his reply to my patch[0]. I agreed to this in my follow-up and asked if
> it would be acceptable to add an additional flag to so that git-branch
> can switch on this request for removal.

So when you rename branch.foo section to branch.bar, instead of
replacing the whole existing branch.bar with what used to be in
branch.foo, you _append_ that to branch.bar?

That sounds insane.

What good does it do to keep what used to be branch.bar?  The
old contents in the section are by no means "valuable".  They
were about 'bar' and do not even have anything to do with the
branch being renamed, which used to be called 'foo'.

Shawn's example of modifying multi-valued variable is
irrelevant.  Over there, we have options to replace everything
or append to it, don't we?

If the option is --rename-section, that is "rename section", not
"merge section".  If for some reason a merge section operation
is needed, that should be supplied in a separate patch, but for
the branch renaming I really do not see the need for it.