Re: .git/info/refs

From: Jakub Narebski <jnareb@gmail.com>
Date: Jan 24, 2007, 17:10 UTC
Message-ID: <ep83m2$mts$1@sea.gmane.org>
In-Reply-To: <45B78C55.2030204@zytor.com>

H. Peter Anvin wrote:

Show 10 quoted lines

> 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

Show 8 quoted lines

>> 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