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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html