git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Han-Wen Nienhuys <hanwenn@gmail.com>,
	Han-Wen Nienhuys <hanwen@google.com>
Subject: Re: [PATCH 3/4] t7004: create separate tags for different tests
Date: Wed, 22 Dec 2021 12:11:07 -0800	[thread overview]
Message-ID: <xmqqo858ien8.fsf@gitster.g> (raw)
In-Reply-To: <854bd15787618978b2da3941b5b749dadc1a186f.1640170784.git.gitgitgadget@gmail.com> (Han-Wen Nienhuys via GitGitGadget's message of "Wed, 22 Dec 2021 10:59:43 +0000")

"Han-Wen Nienhuys via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Han-Wen Nienhuys <hanwen@google.com>
>
> Reftable intentionally keeps reflog data for deleted refs.
>
> This breaks tests that delete and recreate "refs/tags/tag_with_reflog" as traces
> of the deletion are left in reflog. To resolve this, use a differently named ref
> for each test case.
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> ---

Makes sense.  

These tests are *not* trying to see if a ref is recreated, its logs
will reflect only the events after the last such recreation event.

The only thing they care about is that the logs record the events
after the ref was created the last time.

Hmmm, is it?  After spelling it out like the above to make sure I
understand the argument, I am not so sure.  If these tests are
surprised to see reflog entries from the previous life, it will
certainly surprise users and their tools if we suddenly start
showing them without being told.  Their expectation is that a
deletion and recreation is a life resetting event for a ref.

It feels as if we would need a new option in reflog traversal to
take advantage of the new capability reftable offers (i.e. "git
reflog --show-previous-life"), which, use of it is an error if the
backend does not support it.  An alternative is to document it, when
reftable integration happens, as a limitation of files-backend that
it cannot store or show the logs of the ref from its previous life.

I do not care too deeply about it either way right now, because this
patch allows us sidestep the design issue altogether in this test
script.  But we need to think about it when integrating the reftable
backend into refs API.

Thanks.

>  t/t7004-tag.sh | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 082be85dffc..301d1190482 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -94,10 +94,10 @@ test_expect_success 'creating a tag with --create-reflog should create reflog' '
>  	git log -1 \
>  		--format="format:tag: tagging %h (%s, %cd)%n" \
>  		--date=format:%Y-%m-%d >expected &&
> -	test_when_finished "git tag -d tag_with_reflog" &&
> -	git tag --create-reflog tag_with_reflog &&
> -	git reflog exists refs/tags/tag_with_reflog &&
> -	sed -e "s/^.*	//" .git/logs/refs/tags/tag_with_reflog >actual &&
> +	test_when_finished "git tag -d tag_with_reflog1" &&
> +	git tag --create-reflog tag_with_reflog1 &&
> +	git reflog exists refs/tags/tag_with_reflog1 &&
> +	sed -e "s/^.*	//" .git/logs/refs/tags/tag_with_reflog1 >actual &&
>  	test_cmp expected actual
>  '
>  
> @@ -105,10 +105,10 @@ test_expect_success 'annotated tag with --create-reflog has correct message' '
>  	git log -1 \
>  		--format="format:tag: tagging %h (%s, %cd)%n" \
>  		--date=format:%Y-%m-%d >expected &&
> -	test_when_finished "git tag -d tag_with_reflog" &&
> -	git tag -m "annotated tag" --create-reflog tag_with_reflog &&
> -	git reflog exists refs/tags/tag_with_reflog &&
> -	sed -e "s/^.*	//" .git/logs/refs/tags/tag_with_reflog >actual &&
> +	test_when_finished "git tag -d tag_with_reflog2" &&
> +	git tag -m "annotated tag" --create-reflog tag_with_reflog2 &&
> +	git reflog exists refs/tags/tag_with_reflog2 &&
> +	sed -e "s/^.*	//" .git/logs/refs/tags/tag_with_reflog2 >actual &&
>  	test_cmp expected actual
>  '
>  
> @@ -118,10 +118,10 @@ test_expect_success '--create-reflog does not create reflog on failure' '
>  '
>  
>  test_expect_success 'option core.logAllRefUpdates=always creates reflog' '
> -	test_when_finished "git tag -d tag_with_reflog" &&
> +	test_when_finished "git tag -d tag_with_reflog3" &&
>  	test_config core.logAllRefUpdates always &&
> -	git tag tag_with_reflog &&
> -	git reflog exists refs/tags/tag_with_reflog
> +	git tag tag_with_reflog3 &&
> +	git reflog exists refs/tags/tag_with_reflog3
>  '
>  
>  test_expect_success 'listing all tags if one exists should succeed' '

  reply	other threads:[~2021-12-22 20:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22 10:59 [PATCH 0/4] Reftable test fixes 20211221 Han-Wen Nienhuys via GitGitGadget
2021-12-22 10:59 ` [PATCH 1/4] t5540: require REFFILES Han-Wen Nienhuys via GitGitGadget
2021-12-24  5:14   ` Bagas Sanjaya
2022-01-10 18:29     ` Han-Wen Nienhuys
2021-12-22 10:59 ` [PATCH 2/4] t5550: " Han-Wen Nienhuys via GitGitGadget
2021-12-22 10:59 ` [PATCH 3/4] t7004: create separate tags for different tests Han-Wen Nienhuys via GitGitGadget
2021-12-22 20:11   ` Junio C Hamano [this message]
2021-12-22 10:59 ` [PATCH 4/4] t7004: use "test-tool ref-store" for reflog inspection Han-Wen Nienhuys via GitGitGadget
2021-12-22 20:17   ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqo858ien8.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hanwen@google.com \
    --cc=hanwenn@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).