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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html