From: Junio C Hamano Date: Wed, 20 Sep 2006 17:50:38 GMT Subject: Re: [PATCH] Added --mirror-all to git-fetch. Message-ID: <7vu032h1g1.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20060920173126.GG23260@spearce.org> Shawn Pearce writes: > I meant ".git/remotes must have only one file 'origin' and > nothing else". Because what does it mean to mirror two different > repositories at the same time into the same ref namespace? The most > recently fetched would always win. > > But now that I'm writing this I can see someone wanting multiple > remotes so they could store different URLs for the same repository > and call fetch on another if the first isn't responding. So I > retract this entirely. So there doesn't even need to be remotes > file; the URL could just be passed on the command line. A remotes > file (like the default "origin" one) is just a handy place to store > the URL. Another possibility. The mirror might want to do something like: .git/refs/remotes/davem/sparc-2.6.git/... .git/refs/remotes/torvalds/linux-2.6.git/... .git/refs/remotes/jgarzik/netdev-2.6.git/... to be a super-mirror of related projects. This would give a convenient way for the visitors to browse them all at one place, and would save object store. There are minor details such as gitweb may not allow browsing refs/remotes and git-fetch may not let you fetch from refs/remotes (I haven't checked), but they are fixable as needed. > Because we don't want to update HEAD with the SHA1 that's on the > remote if that's actually going to update some other ref which > doesn't have the same value. :-) What I thought you were going to do with HEAD would be to update it not by the object name but modifying where it points at. IOW, if HEAD is a symlink pointing at refs/heads/master and the remote HEAD now points at refs/heads/next, you do not: echo $the_commit_object_name_of_remote_next >.git/HEAD which obviously is insane, but you would do rm -f .git/HEAD && ln -s refs/heads/next .git/HEAD > But I agree with you entirely about HEAD being a SHA1 and not its > actual link target in the network protocol. An annoying bug. Which fortunately is fixable ;-).