On Wed, May 25, 2011 at 10:01:20AM -0700, Shawn O. Pearce wrote: > > and so on. And this fits in with the idea of it not just being an > > upload-pack and receive-pack thing. I could do: > > > > ÂGIT_REF_PREFIX=refs/virtual/repo1; export GIT_REF_PREFIX > > Âgit fetch some-remote > > +1 * 1000. This should be a single environment variable / top level > option. HEAD should also use the GIT_REF_PREFIX, like any other ref. Good, I am glad I'm not the only one thinking this. :) > FETCH_HEAD and MERGE_HEAD probably should as well if GIT_REF_PREFIX is > set, however these are going to be a bit harder to move. Not all tools > that read them are GIT_REF_PREFIX aware, or go through C code that can > be modified to be GIT_REF_PREFIX aware. (git-gui and EGit, I'm talking > about you here!) They can obviously be fixed, but until then using a > working directory with GIT_REF_PREFIX set will be slightly > interesting. Yeah, most scripts these days will need to go through the C programs to handle packed-refs. But the top-level pseudo-refs are a bit more magical. That is perhaps why they split HEAD and refs handling in the original patch. Still, I don't think it's insurmountable. > > So the virtual repository is basically just a "chroot" of the ref > > namespace. And it's dirt simple to implement, because you do the > > translation at the refs.c layer. > > Yes, exactly. Like chroots, there is a sticky point with symbolic links. What should "refs/virtual/repo1/HEAD" have in it? Either: ref: refs/virtual/repo1/refs/heads/master or ref: refs/heads/master ? If the former, then we will have to make sure the ref is inside our prefix, and strip it out. If the latter, then you will get different results for: git show refs/virtual/repo1/HEAD versus GIT_REF_PREFIX=refs/virtual/repo1 git show HEAD which I think is a bad thing. -Peff -- 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