OK, this is quite late, but I've got some news on the subject. On Tue, Aug 9, 2011 at 10:05 PM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Aug 09, 2011 at 12:25:42PM +0200, René Scharfe wrote: > >> > BTW, as nice as this "gzip -cn | cat" idea is, I think it needs to be >> > wrapped in a shell script. With the code above, we will generate "gzip >> > -cn | cat -9". >> >> Yes, the three added lines in the patch above would have to be moved >> down two lines, after the compression level is added. D'oh! > > Also, is adding "| cat" also sufficient for arbitrary shell code (i.e., > whatever the user hands us via the config)? I couldn't think of an > example that wouldn't work. > >> OK, that's one way to do it; another would be let gzip (and bzip2 etc.) >> do whatever cat does to avoid end of line conversions. And yet another >> is to take them from http://unxutils.sourceforge.net/. > > Yeah, I like all of those solutions better than hacking an extra pipe > into git. I don't know enough to say how painful they are in practice, > though. > It turns out, if I compile gzip myself from source the test pass just fine. So the problem seems indeed to be MSYS vs non-MSYS applications. So the way forward is probably to just change to a self-compiled gzip in msysGit (and Git for Windows by proxy). I'll post the patch to build a native-gzip to the msysGit mailing list (I only got 1.2.4 to compile on Windows, but it's the same version as we have in msysGit so it's probably fine), and post the latest version of this series soon... -- 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