Carlos Martín Nieto <cmn@xxxxxxxx> writes:
> The branch command assumes HEAD as the starting point if none is
> specified. This causes --set-upstream to behave unexpectedly if the
> user types
>
> git branch --set-upstream origin/master
>
> git-branch will assume a second argument of HEAD and create config
> entries for a local branch origin/master to track the current
> branch. This is rarely, if ever, what the user wants to do.
>
> Catch invocations with --set-upstream and only one branch so the
> command above sets up the current branch to track origin's master
> branch.
If you look at the set of management operations "git branch"
(i.e. other than "listing" [*1*]) allows you to do, the first name
on the command line always is the branch that is manipulated for
everything other than the "set upstream" operation. In that sense,
the current implementation consistently handles command line
arguments with other options, and your patch breaks the consistency
in the UI.
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:
git checkout frotz
hack hack
# ok, shared infrastructure between two branches are
# sound, and I can build the other topic on top of this
# state
git branch nitfol
# oops, forgot to mark that nitfol is derived on frotz with --track
git branch --set-upstream nitfol
where the last one meant "git branch --set-upstream nitfol frotz",
to retroactively mark the upstream of the named branch, no?
Even though my instinct tends to agree with your "is rarely, if
ever", I do not think it is sane to change the behaviour of a
command that produced one result without failing to produce
something entirely different like your patch does (it would have
been a different story if an operation that everybody got failure
and did not produce a useful result were updated to produce a useful
result).
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.
[Footnote]
*1* The point of "listing" is you do not know the names and asking
the command to produce them, so it is OK to be different. The "set
upstream" operation in question does not share the excuse to be
different.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html