On Wed, May 25, 2011 at 09:07, Jeff King <peff@xxxxxxxx> 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. > 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 ... > 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. -- 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