Shawn Pearce <spearce@xxxxxxxxxxx> 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 ;-).
-
To unsubscribe from this list: 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