On Mon, Oct 11, 2021 at 08:53:11AM -0700, Junio C Hamano wrote: > Bagas Sanjaya <bagasdotme@xxxxxxxxx> writes: > > > +test_expect_success GZIP,BZIP2,XZ 'git archive with gzip, bzip2, and xz filters creates compressed tar archive with proper MIME type' ' > > + git config tar.tar.bz2.command "bzip2 -c" && > > + git config tar.tar.xz.command "xz -c" && > > + git archive --output HEAD.tar.gz --prefix=src/ HEAD && > > I think a lot more portable and robust way to test the feature is to > configure git config tar.tar.test.command (or come up with a name for > a suffix to be used in the test), point it at a script created in this > test script and run git archive with output filename that would trigger > the command. Then, arrange the test to notice if the "test" script was > called with expected command line arguments and standard input. > > That way, you do not need to rely on prereqs and you do not have to > resort to un-portable use of the "file" command. After all, you are > *not* testing if "bzip2 -c" the user happens to have on their $PATH > produces output their "find" recognises as bzip2 compressed. That would work. Or perhaps using something portable like "tr" to do a nonsense conversion, and verifying that we can get convert back to the original. Like say, the tests added to t5000 by 767cf4579f (archive: implement configurable tar filters, 2011-06-21). I don't think the newly proposed test is adding anything beyond that (except checking the system "bzip2" command, but as you say, that is not useful to us, nor portable). -Peff