H. Peter Anvin wrote: > Johannes Schindelin wrote: >> >> Granted, for some things this might work. However, I would not wreak havoc >> by changing the format of .git/info/refs, rather put the details you >> wanted into .git/info/refs-details. > > It's not clear to me if it would be wrecking havoc. After all, if a > format can't be expanded *at all*, there is something wrong, and adding > things to the end of a line is a common structured way of expansion. > Hence the original query 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. 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 >> However, for other things (like showing a certain number of commits), it >> _might_ make sense to cache them (e.g. when literally thousands of people >> look at the 100 last commits of linux-2.6.git), but not for others (e.g. >> the 100th last to the 200th last commit of git-tools.git). > > Any query that's within a repository is fairly easily cachable > post-generation. The front page (and its RSS variant) is a bit of an > exception, because it involves all repositories at once. Actually "RSS", or to be more exact OPML variant of front page in its current invocation is equivalent of project_index page, and it can be generated once (well, once per adding / removing / renaming a repository). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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