Re: [PATCH v3 3/3] Add documentation for virtual repositories

[Jeff King <peff@peff.net>]

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