Stefan Beller <sbeller@xxxxxxxxxx> writes:
> diff --git a/t/t6041-bisect-submodule.sh b/t/t6041-bisect-submodule.sh
> index c6b7aa6..62b8a2e 100755
> --- a/t/t6041-bisect-submodule.sh
> +++ b/t/t6041-bisect-submodule.sh
> @@ -8,7 +8,7 @@ test_description='bisect can handle submodules'
> git_bisect () {
> git status -su >expect &&
> ls -1pR * >>expect &&
> - tar czf "$TRASH_DIRECTORY/tmp.tgz" * &&
> + tar cf "$TRASH_DIRECTORY/tmp.tar" * &&
> GOOD=$(git rev-parse --verify HEAD) &&
> git checkout "$1" &&
> echo "foo" >bar &&
> @@ -20,7 +20,7 @@ git_bisect () {
> git bisect start &&
> git bisect good $GOOD &&
> rm -rf * &&
> - tar xzf "$TRASH_DIRECTORY/tmp.tgz" &&
> + tar xf "$TRASH_DIRECTORY/tmp.tar" &&
> git status -su >actual &&
> ls -1pR * >>actual &&
> test_cmp expect actual &&
While I am fine with taking this (and the other) change, which are
the only sensible response to these bug reports, this makes me
wonder two things and a half.
* Why do we even run "tar", especially without having a
test_when_finished clean-up? Can't there be better ways to test
this and the other one without creating a copy of everything in
the test directory?
* Are we sure the trash directory contents is kept manageable size?
I am primarily worried about this "we are not sure what we will
be clobbering, so let's blindly tar up everything and restore it
later" pattern spreading and people mistakenly use it in tests
that simulate our behaviour on a huge blob with a sparse but
gigantic file.
* Is an addition of 'test_snapshot $tarball *' and 'test_restore
$tarball' pair too much unnecessary refactoring to cater to only
two users of this "let's tar up everything" pattern, given that
we want to _discourage_ use of this pattern in the longer term?
--
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