Junio C Hamano wrote:
> I am not super excited about it either, but at least it is a vast
> improvement compared to the older one, with which it was entirely
> unclear if we are setting the value of upstream *to* what is given
> as an option, or setting the upstream *for* what is given on the
> command line.
Ah, do you mean that --set-upstream is meant to have usage like
"git remote set-url" and co?
git remote set-url <remote> <url>
git branch --set-upstream <branch> <upstream>
That's a reasonable stance, and it seems possible to get used to it.
In that case, we should just teach --set-upstream not to create
new branches, and people will get used to it.
The immediate problem that seems to trip people up is that it is very
tempting to run
git branch --set-upstream junio/master
in an attempt to change what is upstream to the current branch, and
the result is some other completely counterintuitive thing. I suspect
the order of arguments to --set-upstream is a red herring, as long as
it errors out when the arguments are switched to help people catch
mistakes.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
