On Mon, Aug 01, 2011 at 11:52:43PM +0200, René Scharfe wrote: > Am 01.08.2011 23:20, schrieb Johannes Sixt: > > Am 01.08.2011 22:48, schrieb René Scharfe: > >> So git archive gives the right results when writing to a pipe, but > >> always the same wrong result when writing directly to a file. > > > > This could indeed be a CRLF issue. archive-tar.c runs gzip to let it > > write to the original fd 1 (stdout). gzip is an MSYS program, and MSYS > > is "clever" and sets up the channel in text mode (CRLF conversion) if it > > is a regular file, but in binary mode if it is a pipe. > > > > Without the gzip filter, git-archive writes to stdout itself. Since we > > have set up all our channels in binary mode, we do not suffer from the > > same problem for plain tar format. > > > > So, I don't think we can do a lot about it, short of patching MSYS again... > > Or we could pipe the output through us, i.e. attach a builtin version of > cat at the output end of the called command. Only on Windows, of > course. Better ugly and limping then wrong, right? Yeah, that would work. But I am confused. If what Johannes says is true, isn't MSYS gzip totally broken for: # works echo foo | gzip -c | cat >foo.gz # broken; introduces CR echo foo | gzip -c >foo.gz ? (The "works" and "broken" there are my guesses; I don't have a Windows box to test on). IOW, is it simply gzip that is broken, and any fix we do is simply working around a bug in gzip? And therefore the right solution is for MSYS people to fix gzip? -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