git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
May 25, 2011, 17:10 UTC
Message-ID
<20110525171021.GA24038@sigill.intra.peff.net>
In-Reply-To
<BANLkTikwxiBTVdqnQtdvr-VTCm2hSOcRjw@mail.gmail.com>
On Wed, May 25, 2011 at 10:01:20AM -0700, Shawn O. Pearce wrote:
Show 8 quoted lines
> > 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. :)
Show 7 quoted lines
> 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.

Show 5 quoted lines
> > 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
Previous: Shawn PearceNext: Shawn Pearce
Message 6 of 11 in “Support multiple virtual repositories with a single object store and refs”
  1. 1/3 Support multiple virtual repositories with a single object store and refsJamey Sharp, May 25, 2011
  2. 2/3 Support virtual repositories in smart http-backend, specified by environmentJamey Sharp, May 25, 2011
  3. 3/3 Add documentation for virtual repositoriesJamey Sharp, May 25, 2011
  4. Jeff KingMay 25, 2011
  5. Shawn PearceMay 25, 2011
  6. Jeff KingMay 25, 2011
  7. Shawn PearceMay 26, 2011
  8. Junio C HamanoMay 25, 2011
  9. Josh TriplettMay 25, 2011
  10. Junio C HamanoMay 25, 2011
  11. Jamey SharpMay 25, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.