Re: [PATCH] Added --mirror-all to git-fetch.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:41
Shawn Pearce [off-list ref] 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 ;-).