From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Patrick Steinhardt <ps@pks.im>
Subject: [PATCH 1/8] t0600: don't create ref outside of refs/
Date: Mon, 29 Apr 2024 04:16:52 -0400 [thread overview]
Message-ID: <20240429081652.GA228803@coredump.intra.peff.net> (raw)
In-Reply-To: <20240429081512.GA4130242@coredump.intra.peff.net>
We have a test that tries to manipulate the branch refs/heads/referrent,
mostly using either the fully qualified refname or git-branch (which
implies refs/heads/). However, the call to update-ref uses the
unqualified name, meaning we were quietly creating ".git/referrent",
which was otherwise unused by the test.
Fix this to specify refs/heads/referrent.
I _think_ it actually doesn't affect the test outcome either way. The
point of the test is that expiring reflogs for "the_symref" should not
fail when we cannot lock "refs/heads/referrent" that it points to
(because we have created a fake .lock file for it). And that is true
even if the "referrent" file does not even exist. After all, the process
holding the lock could be in the act of creating it.
So I suspect this "update-ref" line could just be dropped entirely.
Which you can verify by going back to its origin in 41d796ed5c (refs:
on symref reflog expire, lock symref not referrent, 2016-04-07) and
removing it. The test fails without the matching code change and passes
with it.
But I think it's worth keeping the update-ref call, as it creates a
situation which is more likely to match what we'd see in the real world.
Even if it does not matter now, it's possible it could in the future.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t0600-reffiles-backend.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0600-reffiles-backend.sh b/t/t0600-reffiles-backend.sh
index 64214340e7..41db9e30d4 100755
--- a/t/t0600-reffiles-backend.sh
+++ b/t/t0600-reffiles-backend.sh
@@ -343,7 +343,7 @@ test_expect_success SHA1 'parsing reverse reflogs at BUFSIZ boundaries' '
test_expect_success 'reflog expire operates on symref not referrent' '
git branch --create-reflog the_symref &&
git branch --create-reflog referrent &&
- git update-ref referrent HEAD &&
+ git update-ref refs/heads/referrent HEAD &&
git symbolic-ref refs/heads/the_symref refs/heads/referrent &&
test_when_finished "rm -f .git/refs/heads/referrent.lock" &&
touch .git/refs/heads/referrent.lock &&
--
2.45.0.rc1.416.gbe2a76c799
next prev parent reply other threads:[~2024-04-29 8:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-29 8:15 [PATCH 0/8] tightening ref handling outside of refs/ Jeff King
2024-04-29 8:16 ` Jeff King [this message]
2024-04-29 8:36 ` Jeff King
2024-04-29 8:42 ` Jeff King
2024-04-29 9:28 ` Patrick Steinhardt
2024-04-30 10:45 ` Jeff King
2024-04-29 15:01 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240429081652.GA228803@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.