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. -hpa - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Jan 25 03:24:45 2007
This archive was generated by hypermail 2.1.8 : 2007-01-25 03:26:32 EST