On Tuesday 07 November 2006 07:54, you wrote: > > IMHO this kind of aliasing is awkward. When you want to start > > another topic branch on the remote branch, or want to reference the > > remote branch for diffs, you have to explicitly specify > > "remotes/origin/next", making for more typing. > > Having more than one local branch for a remote branch is advanced > enough that the user should know how to create branches with any name > they choose. But such an advanced szenario is exactly the reason to introduce these long branch names like "origin/next", isn't it? When a newbie probably never is confronted with this szenario, then why give him longer branch names per default? Do you see the contradiction in this argument? IMHO it should be the other way around: when an advanced user gets this conflict, he knows how to rename the branches by using this more elaborated scheme. I understand that these long branch names implicity give you information about the upstream (by including the remote shortcut in front), but this information (like all branch attributes) should also be easy available with "git branch --info" or similar. Especially, when we introduce shortcuts like "@up" (i.e. git-show-ref @up). > But I do agree that calling it "origin/next" the first time you > branch, and "remotes/origin/next" subsequent times, is nonintuitive. > However, this could be solved by the following message being printed > the first time: > > $ git checkout origin/next > No local branch "origin/next" exists. Creating new local branch > "origin/next" off of remote branch "remotes/origin/next". My patch already does something like this. Josef - 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