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

From: Shawn Pearce <spearce@spearce.org>
Date: May 25, 2011, 17:01 UTC
Message-ID: <BANLkTikwxiBTVdqnQtdvr-VTCm2hSOcRjw@mail.gmail.com>
In-Reply-To: <20110525160708.GE8795@sigill.intra.peff.net>

On Wed, May 25, 2011 at 09:07, Jeff King <peff@peff.net> wrote:

>
> Thinking on the whole idea a bit more, is there a reason to restrict
> this to upload-pack and receive-pack? Sure, they are the most obvious
> places to use it for hosting, but might I not want to be able to do:

No, there isn't. I had the same impression reading this series... that doing it in upload-pack receive-pack was wrong, but I couldn't put my finger on why. I think you did (below), so thank you.

Show 7 quoted lines

>  cd /path/to/mega-repository.git
>  git --ref-prefix=virtual/repo1 log master
>
> to do server-side scripting inside the virtual repos (or more likely,
> setting GIT_REF_PREFIX at the top of your script).
>
>> +The --ref-prefix and --head options provide quite a bit of flexibility

...

Show 19 quoted lines

> I'm curious if you have a use for this much flexibility. In particular,
> why do the HEAD and refs prefixes need the ability to be separate? Also,
> what about other non-HEAD top-level refs? IOW, a true "virtual
> repository" to me would just be:
>
>  GIT_REF_PREFIX=refs/virtual/repo1
>
> and then _every_ ref resolution would just prefix that, whether it was
> in refs/ or not. So you would have:
>
>  .git/refs/virtual/repo1/HEAD
>  .git/refs/virtual/repo1/refs/heads/master
>  .git/refs/virtual/repo1/refs/tags/v1.0
>
> 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.

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.

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

-- 
Shawn.