Re: [PATCH v3 5/5] archive-tar: use internal gzip by default
- From
René Scharfe <l.s.r@web.de>
- Date
- Jun 14, 2022, 15:56 UTC
- Message-ID
- <c67bd455-c643-43e4-3770-7dd891e57b4e@web.de>
- In-Reply-To
- <28f6ec2a-1d94-b29a-4bfd-6a9e74c8edbf@web.de>
Am 14.06.22 um 17:47 schrieb René Scharfe:
Show 22 quoted lines
> Am 14.06.22 um 13:27 schrieb Johannes Schindelin: >> Hi Junio, >> >> On Mon, 13 Jun 2022, Junio C Hamano wrote: >> >>> René Scharfe <l.s.r@web.de> writes: >>> >>>> -test_expect_success GZIP 'git archive --format=tar.gz' ' >>>> +test_expect_success 'git archive --format=tar.gz' ' >>>> git archive --format=tar.gz HEAD >j1.tar.gz && >>>> test_cmp_bin j.tgz j1.tar.gz >>>> ' >>> >>> Curiously, this breaks for me. It is understandable if we are not >>> producing byte-for-byte identical output with internal gzip. > > Makes sense in retrospect, there's no reason the output of gzip(1) and > zlib would have to be the same exactly. It just happened to be so on my > platform, so the tests deceptively passed for me. I think we simply > have to drop those that try to compare compressed files made by > different tools -- we can still check if their content can be extracted > and matches.
I have to take that back, I was confused -- the tests are fine. There are no comparisons between gzip-generated and zlib-generated files. There's just the gzhead use-after-return error that Dscho discovered.
René