Re: .git/info/refs

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.

> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html