Re: [PATCH] Add --no-reuse-delta option to git-gc

Steven Grimm [off-list ref] wrote:

Nicolas Pitre wrote:

quoted

It won't happen for a simple reason: to be backward compatible with 
older GIT clients.  If you have your repo compressed with bzip2 and an 
old client pulls it then the server would have to decompress and 
recompress everything with gzip.  If instead your repo remains with gzip 
and a new client asks for bzip2 then you have to recompress as well 
(slow).  So in practice it is best to remain with a single compression 
method.
 

Not that I really think this is all that important (my original question 
was more out of curiosity than anything) but I don't think those are 
really issues.

...

And since the hypothetical new client would have support for both 
compression types, pulling from a gzip-based repo could be accomplished 
totally transparently; you could, one assumes, even pull from a gzip 
repo and pack locally using the other scheme if you felt like it.

Right, I agree with Steven here.

Pack v4 (which is rapidly becoming vaporware it seems) uses such
a radically different encoding for its commit and tree objects
that you cannot send them as-is to a client unless that client
also understands pack v4.  Consequently you need to decompress and
recompress those objects when talking to an older peer; this isn't
very different from a switch to bzip2.

That said, I think switching to a different generic compressor isn't
that interesting.  We can probably do a lot better by organizing
files into clusters, where those clusters have large number of
symbols in common, and then compress everything in the same cluster
with the same pack-wide dictionary.

Specifically I'm thinking that you may be able to cluster the *.h/*.c
into one cluster, and the Makefile into another, and the .gitignore
into a third cluster, and then leverage the large commonalities
between those blobs when building a dictionary and compressing them.
No, I haven't prototyped it out yet.

-- 
Shawn.