Re: efficient cloning
- From
Petr Baudis <pasky@suse.cz>
- Date
- Mar 20, 2006, 22:41 UTC
- Message-ID
- <20060320224123.GP18185@pasky.or.cz>
- In-Reply-To
- <7vk6aokd7m.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Mar 20, 2006 at 10:39:41PM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that...
Show 9 quoted lines
> 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.