Re: .git/info/refs

From: H. Peter Anvin <hpa@zytor.com>
Date: Jan 24, 2007, 17:06 UTC
Message-ID: <45B79208.2080502@zytor.com>
In-Reply-To: <Pine.LNX.4.63.0701241746390.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 17 quoted lines

> Hi,
> 
> On Wed, 24 Jan 2007, H. Peter Anvin wrote:
> 
>> 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
> 
> The idea of .git/info/refs is to enable dumb transports to fetch something 
> akin to intelligently. They don't need that information, and frankly, I 
> don't think they should need to understand it.

I don't think adding 10 digits to each line is going to be a sizable impact on anything.

> I also expect that they interpret everything after the sha1 as refname, 
> what with our having become quite liberal with refnames (they can contain 
> spaces, tabs, and even a small amount of special K). So I don't see a way 
> to upgrade the file format.

They can also contain newlines, probably, so escaping is obligatory anyway.

> But as should be clear by now, I'd prefer additional information -- that 
> is of no interest to dumb transports anyway -- to be put in an own file.

Yes, but the argument seems to be philosophical.

> That also opens the possibility of, say .git/info/perl/, which contains 
> _only_ serialized perl objects! I imagine this could be a performance 
> booster.

For certain things, I'm sure.

Show 11 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.
> 
> ... and here we have a problem, right? No single update hook can update 
> the _whole_ information.

I don't see a problem.

	-hpa