Re: .git/info/refs

From: H. Peter Anvin <hpa@zytor.com>
Date: Jan 25, 2007, 17:13 UTC
Message-ID: <45B8E551.9020808@zytor.com>
In-Reply-To: <ep83m2$mts$1@sea.gmane.org>

Jakub Narebski wrote:

> 
> I don't think it can be easily expanded. .git/info/refs is meant for
> http-fetch, and it mimics git-ls-remote / git-peek-remote output.

For heaven's sake, in computer science we can *NEVER* use the same feature for *MORE THAN ONE THING*. If it doesn't work format-wise that's fine, but "it's only supposed to be used by dumb transports" is ridiculous.

Show 5 quoted lines

> BTW. putting the info of git-for-each-ref into .git/info/refs-details
> would mean that instead of "24175 calls to git" one would need to
> read 24175 files. Perhaps the whole info needed to generate projects
> index page should be pre-generated on push (update), instead of per
> project (per repository) .git/info/refs-details

No, it should be one file per repository, not one file per ref.  Why? 
Obviously we don't want 24175 files to be accessed.  However, a push can 
only affect files for which the repository owner has permission and 
which resides in the repository filespace, so it should stay inside that 
  space.

On kernel.org, this would reduce the load from 24175 calls to git to reading 250 files. Although the latter is still expensive (and will probably need post-generation caching) the files should be small and cacheable by the kernel, and the resulting I/O load should be quite small.

Anyway, as far as git-update-server-index is concerned, I'm *very* concerned that there be a single command that updates all the cached information across the repository. Telling everyone to update their hooks every time we want to add cached information is silly. Right now, git-update-server-index is the command to update cached information, and for usability reasons there should be a single entry point.

	-hpa