git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] branch: make --set-upstream saner without an explicit starting point

From
Carlos Martín Nieto <cmn@elego.de>
Date
Jul 6, 2012, 07:18 UTC
Message-ID
<1341559103.10752.59.camel@flaca.cmartin.tk>
In-Reply-To
<7vtxxmqezp.fsf@alter.siamese.dyndns.org>
On Thu, 2012-07-05 at 10:44 -0700, Junio C Hamano wrote:
Show 38 quoted lines
> 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*].

Let's do this then. Disregard my earlier patch making -u a synonym of --set-upstream so we can make it a synonym of --set-upstream-to instead. This way we can use -u and then it's not so bad if the long name is a bit ugly.

Show 20 quoted lines
> 
>  * 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

Yep, this seems good. Now that you mention the <name> existing, I wonder if letting --set-upstream create the branch as well wasn't another bad decision, as the name suggests it's for setting that information after the branch has already been created.

> 
>  * 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.

I'd definitely like to deprecate the current behaviour. It's a common source of irritation (not just for me personally, it shows up in #git every once in a while).

I'll probably have some patches to send at the end of the weekend.
   cmn
Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 11 in “branch: make --set-upstream saner without an explicit starting point”
  1. branch: make --set-upstream saner without an explicit starting pointCarlos Martín Nieto, Jul 5, 2012
  2. Jeff KingJul 5, 2012
  3. Carlos Martín NietoJul 5, 2012
  4. Junio C HamanoJul 5, 2012
  5. Junio C HamanoJul 5, 2012
  6. Carlos Martín NietoJul 6, 2012
  7. Junio C HamanoJul 6, 2012
  8. Carlos Martín NietoJul 6, 2012
  9. Junio C HamanoJul 18, 2012
  10. Carlos Martín NietoJul 18, 2012
  11. Junio C HamanoAug 16, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.