Steven Grimm <koreth@xxxxxxxxxxxxx> wrote: > 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. - 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
