Re: .git/info/refs

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 24, 2007, 16:38 UTC
Message-ID: <Pine.LNX.4.63.0701241731400.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <45B78836.5080508@zytor.com>

Hi,

On Wed, 24 Jan 2007, H. Peter Anvin wrote:

Show 19 quoted lines

> Johannes Schindelin wrote:
> > 
> > To me, it seems like all boils down to caching parsed data structures. I.e.
> > parse the config, then serialize the parsed data to a file. Don't reparse
> > the config unless it is 1 hour older than the config.
> > 
> > Likewise, run for-each-ref, and serialize the parsed data into a file. Don't
> > rerun for-each-ref if that file is younger than 15 minutes.
> > 
> > Maybe the same for the first 200 commits of each branch.
> > 
> > (I made those times up, but you get the idea.)
> > 
> 
> A much better idea is to have that data structure updated on repository 
> updates, which is the whole point behind .git/info/refs.  On kernel.org, 
> at least, if you don't keep .git/info/refs up to date you need to get 
> your fingers whacked anyway, since it damages usability for one 
> particular class of users.

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.

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

Having said that, it should be relatively easy to store the (parsed, or at least easily parseable) 500 last commits of a branch into .git/info/commits-<branch>.

This would put the burden of publishing a branch higher, easening the overall load on the server.

Jakub?

Ciao, Dscho