On Thu, 2012-07-05 at 10:44 -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > 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: > > ... > > 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. > > Thinking about it a bit more, I am starting to think that something > based on the "set upstream to" could be a sane way forward: > > * add "git branch [--set-upstream-to=<name>]" that does what your > patch does. The synopsis must make it clear that <name> is not > the usual first <name> like other "branch" command line arguments > that specify the branch being operated on, but is an argument to > the --set-upstream option [*1*]. Let's do this then. Disregard my earlier patch making -u a synonym of --set-upstream so we can make it a synonym of --set-upstream-to instead. This way we can use -u and then it's not so bad if the long name is a bit ugly. > > * when "git branch --set-upstream <name>" without <start point> > is given, you first see if <name> exists and find out the > upstream of <name>, do what the user told you to do (i.e. reset > the upstream of the <name>d branch to the current branch), and > give hints to recover. Two possibilities: > > $ git checkout frotz > $ git branch --set-upstream xyzzy > Branch xyzzy set up to track local branch frotz. > If you wanted to make frotz track xyzzy, do this: > $ git branch --set-upstream xyzzy <original> > $ git branch --set-upstream-to xyzzy > > $ git checkout frotz > $ git branch --set-upstream origin/xyzzy > Branch origin/xyzzy set up to track local branch frotz. > If you wanted to make frotz track xyzzy, do this: > $ git branch -d origin/xyzzy > $ git branch --set-upstream-to origin/xyzzy Yep, this seems good. Now that you mention the <name> existing, I wonder if letting --set-upstream create the branch as well wasn't another bad decision, as the name suggests it's for setting that information after the branch has already been created. > > * possibly, deprecate --set-upstream as a historical wart that had > misdesigned UI, and when it is used, give deprecation warning and > nudge the user to use --set-upstream-to instead. I'd definitely like to deprecate the current behaviour. It's a common source of irritation (not just for me personally, it shows up in #git every once in a while). I'll probably have some patches to send at the end of the weekend. cmn -- 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