On Wed, Jun 15, 2011 at 08:40:22AM +0900, Miles Bader wrote: > Jeff King <peff@xxxxxxxxxx> writes: > >> I didn't know it was that easy (primarily because I didn't know zlib had a > >> ready-to-eat interface to do this). > > > > Yes, though I think it may be worth doing the more flexible, > > external-filters approach. See elsewhere in the thread. > > Given the relatively trivial code, isn't it worth doing both...? > > One method for flexibility/multi-threaded-speed, the other for > portability/robustness (doesn't depend on configuration / setup > details)... Maybe, although the code is a little less trivial than I hoped (see RenÃ's response for some bugs in my original series). My series allowing external filters via configuration also comes with builtin config for gzip. So there's no extra config or setup details for the user, assuming they can run "gzip" from their PATH. So I think the only disadvantage now is for people who don't have gzip at all. I suspect people on such platforms are going to want another format anyway, but we could still help them out. However, I think instead of building it specially into the archive code, it would be cleaner to simply ship a bare-bones version of gzip that only stdio (i.e., a "git-gzip"). It would be no more code than what the internal solution would be, it could be easier to read (since the program is self-contained), and it benefits from the SMP speedup. Although at the point we are shipping "git-gzip", I really have to wonder if people wouldn't prefer to just install gzip themselves. So I'm inclined to wait until somebody complains that git+zlib are easy to get on their system, but gzip isn't. -Peff -- 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