Re: [PATCH] git-http-fetch: Allow caching of retrieved objects byproxy servers

From: sf <sf@b-i-t.de>
Date: Sep 19, 2005, 10:24 UTC
Message-ID: <432E91ED.7050605@b-i-t.de>
In-Reply-To: <Pine.LNX.4.62.0509181720290.14003@qynat.qvtvafvgr.pbz>

David Lang wrote:

Show 15 quoted lines

> On Wed, 14 Sep 2005, sf wrote:
> 
>> Sergey Vlasov wrote:
>>
>>> By default the curl library adds "Pragma: no-cache" header to all
>>> requests, which disables caching by proxy servers.  However, most
>>> files in a GIT repository are immutable, and caching them is safe and
>>> could be useful.
>>
>>
>> Is caching really safe? Because of compression one git object can have 
>> many file representations.
> 
> 
> only if you use different compression algorithums.

Even different implementations and different compression levels can lead to different file representations.

> remember that git objects are identified by their sha1, if the sha1 is 
> what you want (and the file matches the sha1 after you decompress it) 
> then it really doesn't matter what it's on-disk representation is.

You are arguing on the git tool level but we are talking about HTTP which knows nothing about the uncompressed sha1.

The OP assumed that "files in a GIT repository are immutable" which is not true. If you consider the sequence

pack -> prune -> update zlib or git -> unpack

you can end up with different files if the new zlib implementation changes imcompatibly (with respect to byte-by-byte compression results) or if git suddenly does not use the default compression level any more.

And surely in the future there will be other git implementations than this one which may not even use zlib.

I do not say that caching is not possible at all but HTTP caching has its pitfalls so just be careful.

Regards

	Stephan