From: Junio C Hamano <gitster@pobox.com>
To: Kristoffer Haugsbakk <code@khaugsbakk.name>
Cc: git@vger.kernel.org, peff@peff.net
Subject: Re: [PATCH 2/3] t/t7004-tag: add failing tag message file test
Date: Mon, 15 May 2023 00:00:38 -0700 [thread overview]
Message-ID: <xmqqa5y6axk9.fsf@gitster.g> (raw)
In-Reply-To: 1f24aa43f70b16381ef0cfb4f1d482706161554d.1684067644.git.code@khaugsbakk.name
Kristoffer Haugsbakk <code@khaugsbakk.name> writes:
> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
> ---
> t/t7004-tag.sh | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Does this document the current behaviour, i.e. before applying the
patch [3/3]? Or is this a new test designed to fail until [3/3] is
applied?
If the latter, please don't [*].
Instead, combine this with [3/3] and make it [2/2] that changes the
behaviour of the command and protects the new behaviour from future
breakages in a single step. Those who are truly curious to see why
the code change in it is necessary can apply the "code change plus
new test" patch, and then temporarily revert only the code change
part in their working tree to see how the test breaks without the
code change.
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 550b5b1cce..1e512dbe06 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -2136,4 +2136,14 @@ test_expect_success 'If tag is created then tag message file is unlinked' '
> ! test -e .git/TAG_EDITMSG
> '
>
> +test_expect_success 'If tag cannot be created then tag message file is not unlinked' '
> + test_when_finished "git tag -d foo/bar" &&
> + write_script fakeeditor <<-\EOF &&
> + echo Message >.git/TAG_EDITMSG
> + EOF
> + git tag foo/bar &&
> + ! GIT_EDITOR=./fakeeditor git tag -a foo &&
Imitate other tests that expect a controlled failure from our
command, and write something like
test_must_fail env GIT_EDITOR=./fakeeditor git tag -a foo
so that a segfaulting "git tag" will not count as "failing as
expected".
> + test -e .git/TAG_EDITMSG
Use "test_path_exists" instead.
Thanks.
[Footnote]
* Introducing this as a failing test "test_expect_failure" in [2/3]
and then flip it to "test_expect_success" in [3/3] would make
tests pass without applying [3/3], but generally it is not a
recommended practice.
This is because such a [3/3] patch would only show the line with
the test title and the behaviour of the test will not be shown in
the diff context. That hurts reviewability.
next prev parent reply other threads:[~2023-05-15 7:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-14 13:17 [PATCH 0/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-14 13:17 ` [PATCH 1/3] t/t7004-tag: add regression test for existing behavior Kristoffer Haugsbakk
2023-05-15 6:59 ` Junio C Hamano
2023-05-14 13:17 ` [PATCH 2/3] t/t7004-tag: add failing tag message file test Kristoffer Haugsbakk
2023-05-15 7:00 ` Junio C Hamano [this message]
2023-05-15 19:56 ` Kristoffer Haugsbakk
2023-05-15 7:02 ` Junio C Hamano
2023-05-14 13:18 ` [PATCH 3/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-15 6:59 ` Junio C Hamano
2023-05-15 20:29 ` [PATCH v2 0/3] " Kristoffer Haugsbakk
2023-05-15 20:29 ` [PATCH v2 1/3] doc: tag: document `TAG_EDITMSG` Kristoffer Haugsbakk
2023-05-15 21:59 ` Junio C Hamano
2023-05-15 20:29 ` [PATCH v2 2/3] t/t7004-tag: add regression test for successful tag creation Kristoffer Haugsbakk
2023-05-15 20:29 ` [PATCH v2 3/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-15 21:50 ` [PATCH v2 0/3] " Junio C Hamano
2023-05-16 17:55 ` [PATCH v3 " Kristoffer Haugsbakk
2023-05-16 17:55 ` [PATCH v3 1/3] doc: tag: document `TAG_EDITMSG` Kristoffer Haugsbakk
2023-05-16 17:55 ` [PATCH v3 2/3] t/t7004-tag: add regression test for successful tag creation Kristoffer Haugsbakk
2023-05-16 17:55 ` [PATCH v3 3/3] tag: keep the message file in case ref transaction fails Kristoffer Haugsbakk
2023-05-16 18:39 ` [PATCH v3 0/3] " Junio C Hamano
2023-05-17 9:32 ` [PATCH " Jeff King
2023-05-17 16:00 ` Junio C Hamano
2023-05-17 17:37 ` Jeff King
2023-05-17 17:52 ` Eric Sunshine
2023-05-17 18:02 ` Kristoffer Haugsbakk
2023-05-17 19:58 ` Kristoffer Haugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa5y6axk9.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).