Dear diary, on Mon, Mar 20, 2006 at 10:39:41PM CET, I got a letter where Junio C Hamano <junkio@xxxxxxx> said that... > You are commenting on the initial 'git-clone' and specifically > on one of its optional feature. What multiple upstreams? > > The whole point of what git-clone does on top of making a > straight clone of the remote is to give you a reasonable > starting point. The traditional "master" -> "origin" mapping is > good for cloning a typical single-head repository. If your > upsteram has more branches, --use-separate-remote would help you > to start your branch namespace uncluttered. Yes, but I just see no connecting with a "starting point" whatsoever - why should this be inherent to initial clone? I can see no greater chance that I will want all the branches than when I want to fetch from another repository later (especially in a truly distributed environment). So, it doesn't make sense to me to limit this feature only to the initial clone case - I want to be able to reasonably "fetch all branches" of any repository I wish. Without massive namespace clashes, the reasonable way is to just have a separate directory in .git/refs/remotes/ for each repository (and it's my understanding that this was the original proposal as well). Then you can make a simple change that if a refname matches a directory in refs/remotes/, you rewrite it as refs/remotes/<refname>/master. This makes 'origin' work seamlessly in a natural way and a lot more elegantly than if you make up an artifical rule like "if the remote's branch is master, save it as origin, but save all the other branches verbatim". -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Right now I am having amnesia and deja-vu at the same time. I think I have forgotten this before. - : 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