git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: SURA <surak8806@gmail.com>, Taylor Blau <me@ttaylorr.com>,
	git@vger.kernel.org
Subject: Re: The transfer.hideRefs of the upload-pack process does not work properly
Date: Tue, 4 Mar 2025 12:38:50 +0100	[thread overview]
Message-ID: <Z8bmSj_Ds7ePpzBM@pks.im> (raw)
In-Reply-To: <20250304075146.GA1297781@coredump.intra.peff.net>

On Tue, Mar 04, 2025 at 02:51:46AM -0500, Jeff King wrote:
> On Tue, Mar 04, 2025 at 02:51:14AM -0500, Jeff King wrote:
> 
> > From your reproduction, it looks like the issue is that for loose refs,
> > asking for_each_ref() to exclude "refs/heads/foo" will not yield
> > "refs/heads/foo/bar", but will yield "refs/heads/foo-bar".
> > 
> > And that was true for packed-refs, too, before 59c35fac54
> > (refs/packed-backend.c: implement jump lists to avoid excluded
> > pattern(s), 2023-07-10). After that, packed-refs exclude both.
> 
> Oh, and of course it would be interesting to know how reftables behave
> here, too, as I think they recently learned about exclusions.

Well, we have tests that explicitly verify that prefixes cause us to
exclude such refs in t1419, "overlapping exclude regions". So the
reftable backend is bug-compatible :)

Guess we'll need something similar to the following:

diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
index 7e90e13f745..45462f2ce6d 100644
--- a/refs/reftable-backend.c
+++ b/refs/reftable-backend.c
@@ -594,6 +594,16 @@ static int should_exclude_current_ref(struct reftable_ref_iterator *iter)
 		if (cmp < 0)
 			return 0;
 
+		/*
+		 * The exclude pattern needs to either match exactly, or, if it
+		 * is a prefix of the given reference, it must be a containing
+		 * directory.
+		 */
+		if (iter->ref.refname[iter->exclude_patterns_strlen] &&
+		    pattern[iter->exclude_patterns_strlen - 1] != '/' &&
+		    iter->ref.refname[iter->exclude_patterns_strlen] != '/')
+			return 0;
+
 		/*
 		 * The reference shares a prefix with the exclude pattern and
 		 * shall thus be omitted. We skip all references that match the

Patrick

  reply	other threads:[~2025-03-04 11:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  7:24 The transfer.hideRefs of the upload-pack process does not work properly SURA
2025-02-28  0:12 ` Taylor Blau
2025-02-28  2:32   ` SURA
2025-03-04  7:51     ` Jeff King
2025-03-04  7:51       ` Jeff King
2025-03-04 11:38         ` Patrick Steinhardt [this message]
2025-03-04 16:40           ` Taylor Blau
2025-03-06  1:21             ` Taylor Blau
2025-03-05 23:12       ` Taylor Blau
2025-03-05 23:45         ` 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=Z8bmSj_Ds7ePpzBM@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=surak8806@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.
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 NNTP newsgroup(s).