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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 11, 2007, 06:31 UTC
Message-ID: <20070611063118.GF6073@spearce.org>
In-Reply-To: <466CE998.9000706@midwinter.com>

Steven Grimm <koreth@midwinter.com> wrote:

Show 14 quoted lines

> Nicolas Pitre wrote:
> >
> >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.