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

[Jonas Fonseca <fonseca@diku.dk>]

Junio C Hamano <gitster@pobox.com> wrote Fri, Nov 02, 2007:
> Jonas Fonseca <fonseca@diku.dk> writes:
> 
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> > ---
> >  Documentation/git-branch.txt |    5 +++++
> >  1 files changed, 5 insertions(+), 0 deletions(-)
> >
> >  I made a patch to discard the overwritten branch's configuration
> >  section, which Spearce felt was too lossy a behaviour. However, since
> >  it confused me, I think it should at least be mentioned in the manpage.
> >  Maybe the warning message from git should also be added to improve its
> >  "googlability".
> >
> > diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> > index 5e81aa4..def4e85 100644
> > --- a/Documentation/git-branch.txt
> > +++ b/Documentation/git-branch.txt
> > @@ -165,6 +165,11 @@ If you are creating a branch that you want to immediately checkout, it's
> >  easier to use the git checkout command with its `-b` option to create
> >  a branch and check it out with a single command.
> >  
> > +When a branch is renamed so that it overwrites an existing branch unintended
> > +problems can arise. This is because git refuses to discard the configuration
> > +section of the overwritten branch. As a result git can become confused if, for
> > +example, the branches involved were used for tracking two different remote
> > +branches. The only way to fix this is to edit the configuration file manually.
> 
> I do not understand this bit about "refuse".
> 
>  - To "refuse to discard", somebody has to ask to discard ---
>    who asks so and when?

IMO, the user asks when using git-branch -M. And in case it is not clear
the problem arises for the command sequence:

	$ git branch --track o-next origin/next
	$ git branch --track m-next madcoder/next
	$ git branch -M o-next m-next
	$ git remote
	Warning: more than one branch.m-next.remote
	...

>  - Is there a reason to "refuse" when such a removal request is
>    made?  If so, what is it?  If not, why refusal?

Personally, I don't see why we need to refuse, since git-branch -M is
somewhat similar to saying -m (rename) plus adding a "force" flag
meaning: "yes, I know that this will potentially throw away settings for
an already existing branch".

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.

[0] http://thread.gmane.org/gmane.comp.version-control.git/61291

-- 
Jonas Fonseca