Re: branch --set-upstream considered harmful

Jay Soffian venit, vidit, dixit 06.06.2010 21:21:

Say I have an existing branch and it doesn't have a tracking config.
(My local users often just do "checkout -b topic" instead of "checkout
-b topic origin/master".)

I would naively expect this to work, while on that branch:

  (topic)$ git branch --set-upstream origin/master

But, um no:

  (topic)$ git branch --set-upstream origin/master
  Branch origin/master set up to track local branch topic.

Doh!

Well, maybe this works:

  (topic)$ git branch --set-upstream origin/master topic
  Branch origin/master set up to track local branch topic.

Doh!^2

Well, maybe we can say "HEAD" since that seems to mean "the current
branch" everywhere else in gitland:

  (topic)$ git branch --set-upstream HEAD origin/master
  Branch HEAD set up to track remote branch master from origin.

(Aside, being able to create a branch named HEAD is surely a bug, right?)

Finally after exhausting all other possibilities (or finally making
sense of --set-upstream in the man page), we realize:

  (topic)$ git branch --set-upstream topic origin/master
  Branch topic set up to track remote branch master from origin.

Trying to make myself feel better, I realize that this works:

  (topic)$ git branch topic --set-upstream origin/master

So here's how I'm thinking about fixing it, but maybe I'm just making
it even more confusing. What say you:

  (topic)$ git branch --set-upstream=origin/master
  Branch topic set up to track remote branch master from origin.

--track would be similarly enhanced, which allows a little more
flexibility in creating a branch thusly:

  $ git branch --track=origin/master topic

Which creates topic, starting from HEAD, but tracking origin/master.
(And I'd do the same for checkout's --track option.)

I recognize that having both positional and non-positional forms of
--track/--set-upstream  may be confusing, but I think it's less
confusing than set-upstream's current semantics, I'm loathe to
introduce yet another option, and I don't want to break backward
compatibility.

Flames?

I'm sorry, but you're completely right. I created a tracking branch
config *for* a remote branch myself, and created one for the HEAD branch
before looking up the man page and wondering about the braindead
non-semantic way it works. We have that braindeadness in other places as
well, e.g. "git rebase branchname" which does not rebase "branchname" at
all (but the current branch).

Ok, you want flame? I'll give you flame: This is not going to change. We
have a "naturally grown" ui, and we don't do any changes to make it
conceptually consistent unless it does not change any existing
behaviour. [I'm exaggerating, of course, but you wanted flame, didn't you? ]

I like your --set-upstream= solution, by the way. Maybe people find it
less confusing if there's an "--upstream=upstream" long option (no
"set") and a "--set-upstream" subcommand. You know we have subcommands
as options as well as arguments:

branch --set-upstream
config --get etc.
remote add etc.
noted edit etc.
svn init etc.
submodule add etc.

Speaking of consistency :|

Michael