[PATCH] t7004: check existence of correct tag

[PATCH] t7004: check existence of correct tag

[Martin Ågren]

We try to delete the non-existing tag "anothertag", but for the
verifications, we check that the tag "myhead" doesn't exist. "myhead"
isn't used in this test except for this checking. Comparing to the test
two tests earlier, it looks like a copy-paste mistake.

Perhaps it's overkill to check that `git tag -d` didn't decide to
*create* a tag. But since we're trying to be this careful, let's
actually check the correct tag. While we're doing this, let's use a more
descriptive tag name instead -- "nonexistingtag" should be obvious.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---

 > Probably worth inspecting the output of that `git tag -d` a bit in
 > t7004, to make sure we just claim to delete one tag, and have errors.

 Here's something I noticed while looking into this test. If you do
 expand on this test, feel free to pick this up, either as a preparatory
 patch or squash it into your "expand test" patch (if you do one). If
 you don't pick this up at all, I'll pursue it separately, later.

 Martin

 t/t7004-tag.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 80eb13d94e..e4cf605907 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -227,10 +227,10 @@ test_expect_success \
 test_expect_success \
 	'trying to delete two tags, existing and not, should fail in the 2nd' '
 	tag_exists mytag &&
-	! tag_exists myhead &&
-	test_must_fail git tag -d mytag anothertag &&
+	! tag_exists nonexistingtag &&
+	test_must_fail git tag -d mytag nonexistingtag &&
 	! tag_exists mytag &&
-	! tag_exists myhead
+	! tag_exists nonexistingtag
 '
 
 test_expect_success 'trying to delete an already deleted tag should fail' \
-- 
2.23.0.rc0.30.g51cf315870

[PATCH] t7004: check existence of correct tag

[Martin Ågren]

We try to delete the non-existing tag "anothertag", but for the
verifications, we check that the tag "myhead" doesn't exist. "myhead"
isn't used in this test except for this checking. Comparing to the test
two tests earlier, it looks like a copy-paste mistake.

Perhaps it's overkill to check that `git tag -d` didn't decide to
*create* a tag. But since we're trying to be this careful, let's
actually check the correct tag. While we're doing this, let's use a more
descriptive tag name instead -- "nonexistingtag" should be obvious.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
 This is a resend of
 https://public-inbox.org/git/20190808125330.3104954-1-martin.agren@gmail.com/

 t/t7004-tag.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 80eb13d94e..e4cf605907 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -227,10 +227,10 @@ test_expect_success \
 test_expect_success \
 	'trying to delete two tags, existing and not, should fail in the 2nd' '
 	tag_exists mytag &&
-	! tag_exists myhead &&
-	test_must_fail git tag -d mytag anothertag &&
+	! tag_exists nonexistingtag &&
+	test_must_fail git tag -d mytag nonexistingtag &&
 	! tag_exists mytag &&
-	! tag_exists myhead
+	! tag_exists nonexistingtag
 '
 
 test_expect_success 'trying to delete an already deleted tag should fail' \
-- 
2.24.0

Re: [PATCH] t7004: check existence of correct tag

[Jeff King]

On Wed, Nov 13, 2019 at 08:39:02PM +0100, Martin Ågren wrote:

> We try to delete the non-existing tag "anothertag", but for the
> verifications, we check that the tag "myhead" doesn't exist. "myhead"
> isn't used in this test except for this checking. Comparing to the test
> two tests earlier, it looks like a copy-paste mistake.

Thanks, the description and patch look good to me.

> Perhaps it's overkill to check that `git tag -d` didn't decide to
> *create* a tag. But since we're trying to be this careful, let's
> actually check the correct tag. While we're doing this, let's use a more
> descriptive tag name instead -- "nonexistingtag" should be obvious.

Yes, that would be a spectacular bug indeed. :)

I think it's fine to keep it in, though, as it communicates the
expectations pretty clearly.

-Peff