From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Thu, 29 Sep 2011 19:54:04 GMT
Subject: Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
Message-ID: <CABPQNSba+nQ+AOmVEVNWhJi2e65EiuhRxfOWZsW03Pkc6zXdHg@mail.gmail.com>
In-Reply-To: <20110809200504.GA31944@sigill.intra.peff.net>

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@peff.net> 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...