Re: .git/info/refs

[Jakub Narebski <jnareb@gmail.com>]

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