From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 05 Jul 2012 17:44:58 GMT
Subject: Re: [PATCH] branch: make --set-upstream saner without an explicit starting point
Message-ID: <7vtxxmqezp.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vd34arvhu.fsf@alter.siamese.dyndns.org>

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

> I think it was a mistake that nobody noticed that it is likely that
> the operation most often will be done for the current branch and the
> usual "give me one branch name to operate on, or I'll operate on the
> current branch" command line convention of "git branch" commannd is
> not a good fit for it, when "set upstream" feature was added, and
> suggested an alternative syntax that avoids the mistake you quoted
> above, perhaps something like:
>
> 	git branch --set-upstream-to=origin/master [HEAD]
>
> which would have been very clear whose upstream is set to what (with
> or without the name of the other branch).  In other words, make the
> name "origin/master" *NOT* the first branch name on the command line
> in the usual sense, but a parameter to the --set-upstream option, so
> that "give me one branch name to operate on, or I'll operate on the
> current branch" convention is still kept.
> 
> You also broke people who corrected another kind of mistake in this
> workflow:
> ...
> Coming from the above observation, while I am sympathetic to your
> cause and agree that we would want to do something about it, I am
> having a hard time to convince myself that your patch is the best
> way to go.
>
> I am not entirely happy with the hypothetical "set-upstream-to"
> myself, either.

Thinking about it a bit more, I am starting to think that something
based on the "set upstream to" could be a sane way forward:

 * add "git branch [--set-upstream-to=<name>]" that does what your
   patch does.  The synopsis must make it clear that <name> is not
   the usual first <name> like other "branch" command line arguments
   that specify the branch being operated on, but is an argument to
   the --set-upstream option [*1*].

 * when "git branch --set-upstream <name>" without <start point>
   is given, you first see if <name> exists and find out the
   upstream of <name>, do what the user told you to do (i.e. reset
   the upstream of the <name>d branch to the current branch), and
   give hints to recover.  Two possibilities:

     $ git checkout frotz
     $ git branch --set-upstream xyzzy
     Branch xyzzy set up to track local branch frotz.
     If you wanted to make frotz track xyzzy, do this:
       $ git branch --set-upstream xyzzy <original>
       $ git branch --set-upstream-to xyzzy

     $ git checkout frotz
     $ git branch --set-upstream origin/xyzzy
     Branch origin/xyzzy set up to track local branch frotz.
     If you wanted to make frotz track xyzzy, do this:
       $ git branch -d origin/xyzzy
       $ git branch --set-upstream-to origin/xyzzy

 * possibly, deprecate --set-upstream as a historical wart that had
   misdesigned UI, and when it is used, give deprecation warning and
   nudge the user to use --set-upstream-to instead.


[Footnote]

*1* The parseopt parser will allow both of:

    $ git branch --set-upstream-to=origin/master
    $ git branch --set-upstream-to origin/master

    but the braket around the option name "--set-upstream-to" and
    its argument <name> should make it clear, i.e.

	git branch [--set-upstream-to <name>] [<branch>]

    or

    	git branch [--set-upstream-to=<name>] [<branch>]