[PATCH] t3419: prevent failure when run with EXPENSIVE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This test runs a function which itself runs several assertions.  The
last of these assertions cleans up the .git/rebase-apply directory,
since when run with EXPENSIVE set, the function is invoked a second time
to run the same tests with a larger data set.

However, as of 2ac0d6273f ("rebase: change the default backend from "am"
to "merge"", 2020-02-15), the default backend of rebase has changed, and
cleaning up the rebase-apply directory has no effect: it no longer
exists, since we're using rebase-merge instead.

Since we don't really care which rebase backend is in use, let's just
clean up both, which means we'll do the right thing in every case.

Signed-off-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx>
---
I noticed this when I was working on another series and running the
testsuite with GIT_TEST_LONG=1.  We'll probably want to add this before
the release if possible.

It may also be desirable to have at least once CI run that runs this
way.  In my experience, it does not take substantially longer to run the
testsuite on a modern Linux system with this option enabled.

 t/t3419-rebase-patch-id.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t3419-rebase-patch-id.sh b/t/t3419-rebase-patch-id.sh
index 94552669ae..824d84f9ce 100755
--- a/t/t3419-rebase-patch-id.sh
+++ b/t/t3419-rebase-patch-id.sh
@@ -91,7 +91,7 @@ do_tests () {
 		git commit -q -m squashed &&
 		git checkout -q other^{} &&
 		test_must_fail git rebase squashed &&
-		rm -rf .git/rebase-apply
+		rm -rf .git/rebase-merge .git/rebase-apply
 	'
 }
 



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux