Hi, On Wed, 24 Jan 2007, hpa@xxxxxxxxx wrote: > > H. Peter Anvin wrote: > > > >>> Besides, we can't rely that .git/info/refs is up to date, or even > >>> exists. > >>> It is for dumb protocols, not for gitweb. > >> > >> Well, SOMETHING needs to be done for this page, since it can take 15 > >> minutes or more to generate. Caching doesn't help one iota, since it's > >> stale before being generated. > > > > The simple and fast solution would be to make post-update hook contain > > the git-for-each-ref with parameters like in git_get_last_activity, > > saving e.g. to .git/info/last-committer, and in gitweb read this file > > if it exist, run git-for-each-ref otherwise (similar to what we used to > > do with .git/info/refs and git-peek-remote in gitweb). > > > > Right, this is basically what I'm saying; the question is only whether or > not this fits into .git/info/refs or should be a separate file. > > Either way, I think git-update-server-info should generate all these files. Well, no. At least not per default. What you want is _very_ special to gitweb. It is _only_ needed by gitweb. And .git/info/refs is for _dumb transports_, _not_ for gitweb. That said, I think it makes sense _in your setup_ to trigger updating _another_ file for use in gitweb. Remember, this is all very, very special for gitweb. So let's separate it cleanly from all which is not special for gitweb. I hope I have made it clear why (at least IMHO) it would be wrong, wrong, wrong to change the format of .git/info/refs _only_ for gitweb, which it is not meant for to begin with. So let's introduce another file in .git/info/ especially dedicated to gitweb. Then we are free to introduce real cool performance hacks, like using Storable to store the parsed data structures (I was alluding to this in an earlier reply, as "serializing"). Then you just retrieve the file -- if it exists -- or call for-each-ref (like Jakub said). By separating this gitweb-special thing cleanly, maybe into a hook, we can have a perl script which writes this file. We can write a simple hash, which may or may not contain keys, thus being of "extensible format". By having this perl script, you can -- as root -- run it as the appropriate user for each repository where it does not exist yet. Remains the problem: how do we _force_ this hook enabled site-wide, i.e. in _all_ repos? But that is too easy: just edit the existing template, and then replace the update hooks in all repos (possibly verifying that the existing update hook indeed matches the old template). So what problems remain with this approach? 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