Re: [PATCH] Added --mirror-all to git-fetch.

From: Junio C Hamano <junkio@cox.net>
Date: Sep 20, 2006, 17:50 UTC
Message-ID: <7vu032h1g1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060920173126.GG23260@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 12 quoted lines

> 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 ;-).