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.
Even with a better compression scheme, nobody would want to remove gzip
support; if you are creating a repo that needs to be compatible with old
clients -- and of course not all repositories need that -- you'd just
configure it to use gzip (or more likely, *not* configure it to use the
other method.) There are already options whose documentation says,
"Don't enable this if you want your repo to be accessed by git clients
older than version X." In other words, git already has an established
approach for adding new non-backward-compatible features. Some projects,
e.g. internal corporate ones, can mandate that everyone upgrade their
clients, and more importantly, once any new git feature has been out for
a long enough time, even public projects can reasonably say, "You need
version X to access our repo." If alternate compression were introduced
today, in five years would anyone care that there'd be some ancient,
ancient clients that couldn't use it?
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.
-Steve