branch --set-upstream considered harmful

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?

j.

Hi,

On Mon, Jun 7, 2010 at 3:21 AM, Jay Soffian <jaysoffian@gmail.com> wrote:

Hmm, I can see where the confusion is coming from - you're treating git-branch as a "branch modifier", when it really is a "branch creator" - unless you use -f, of course.

I was under the impression that long-style options took "=".

On Mon, Jun 7, 2010 at 1:10 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:

Given --set-upstream's implementation and documentation, I assume it is primarily intended to be used with an existing branch:

       --set-upstream
           If specified branch does not exist yet or if --force has been
           given, acts exactly like --track. Otherwise sets up configuration
           like --track would when creating the branch, except that where
           branch points to is not changed.

If it isn't, then there's no way to do what it does other than two magical git config commands.

Git is inconsistent. Some do, some don't. But --set-upstream is currently an argumentless switch. If I were to proceed as I suggested, it would be both an argumentless switch and an option which takes an argument. That means these would be equivalent:

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

But these WOULD NOT:

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

j.

Jay Soffian wrote:

[...]

Doesn't this just make it *more* confusing?

Either we document this, and the user will be left wondering why we have two almost identical (and by the conventions of many other programs, including git-send-email, *equivalent*) syntaxes doing, well, something not quite entirely unlike the same.

Or we don't, and the user will eventually typo it and wonder WTF he just did wrong.

On Mon, Jun 7, 2010 at 2:37 AM, Thomas Rast <trast@student.ethz.ch> wrote:

Please take a step back and see my original message. The thing that motivated this is that the existing invocation is, I claim, bass-ackwards. I was merely looking for a backwards compatible solution that doesn't introduce yet another argument. But, maybe set-upstream hasn't been around so long that breaking it (i.e., making it an option that requires an argument) wouldn't be a bad idea.

Enough talk, I'll send up a patch when I get some more time.

j.

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

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