Hi, On Wed, 24 Jan 2007, H. Peter Anvin wrote: > 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 - 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