From: Junio C Hamano <gitster@pobox.com>
To: Victoria Dye <vdye@github.com>
Cc: Patrick Steinhardt <ps@pks.im>,
Victoria Dye via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/4] ref-cache.c: fix prefix matching in ref iteration
Date: Mon, 09 Oct 2023 11:15:06 -0700 [thread overview]
Message-ID: <xmqqa5sr1x3p.fsf@gitster.g> (raw)
In-Reply-To: <3585d72f-9f06-d190-ad5a-bec6db3f647f@github.com> (Victoria Dye's message of "Mon, 9 Oct 2023 09:21:53 -0700")
Victoria Dye <vdye@github.com> writes:
> I originally operated on the assumption that it was the first case, which is
> why I didn't include a test in this patch. Commands like 'for-each-ref',
> 'show-ref', etc. either use an empty prefix or a directory prefix with a
> trailing slash, which won't trigger this issue.
Ah, yes, I didn't mention it but I suspected as such (i.e. the code
is structured in such a way that this broken implementation does not
matter to the current callers).
> I encountered the problem
> while working on a builtin that filtered refs by a user-specified prefix -
> the results included refs that should not have been matched, which led me to
> this fix.
OK, perfectly understandable.
> Scanning through the codebase again, though, I do see a way to replicate the
> issue:
>
> $ git update-ref refs/bisect/b HEAD
> $ git rev-parse --abbrev-ref --bisect
> refs/bisect/b
>
> Because 'rev-parse --bisect' uses the "refs/bisect/bad" prefix (no trailing
> slash) and does no additional filtering in its 'for_each_fullref_in'
> callback, refs like "refs/bisect/b" and "refs/bisect/ba" are (incorrectly)
> matched. I'll re-roll with the added test.
Good find. Thanks!
next prev parent reply other threads:[~2023-10-09 18:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 18:09 [PATCH 0/4] Performance improvement & cleanup in loose ref iteration Victoria Dye via GitGitGadget
2023-10-06 18:09 ` [PATCH 1/4] ref-cache.c: fix prefix matching in " Victoria Dye via GitGitGadget
2023-10-06 21:51 ` Junio C Hamano
2023-10-09 10:04 ` Patrick Steinhardt
2023-10-09 16:21 ` Victoria Dye
2023-10-09 18:15 ` Junio C Hamano [this message]
2023-10-06 18:09 ` [PATCH 2/4] dir.[ch]: expose 'get_dtype' Victoria Dye via GitGitGadget
2023-10-06 22:00 ` Junio C Hamano
2023-10-06 18:09 ` [PATCH 3/4] dir.[ch]: add 'follow_symlink' arg to 'get_dtype' Victoria Dye via GitGitGadget
2023-10-06 18:09 ` [PATCH 4/4] files-backend.c: avoid stat in 'loose_fill_ref_dir' Victoria Dye via GitGitGadget
2023-10-06 22:12 ` Junio C Hamano
2023-10-06 19:09 ` [PATCH 0/4] Performance improvement & cleanup in loose ref iteration Junio C Hamano
2023-10-09 10:04 ` Patrick Steinhardt
2023-10-09 21:49 ` Victoria Dye
2023-10-10 7:21 ` Patrick Steinhardt
2023-10-09 21:58 ` [PATCH v2 " Victoria Dye via GitGitGadget
2023-10-09 21:58 ` [PATCH v2 1/4] ref-cache.c: fix prefix matching in " Victoria Dye via GitGitGadget
2023-10-10 7:21 ` Patrick Steinhardt
2023-10-09 21:58 ` [PATCH v2 2/4] dir.[ch]: expose 'get_dtype' Victoria Dye via GitGitGadget
2023-10-09 21:58 ` [PATCH v2 3/4] dir.[ch]: add 'follow_symlink' arg to 'get_dtype' Victoria Dye via GitGitGadget
2023-10-09 21:58 ` [PATCH v2 4/4] files-backend.c: avoid stat in 'loose_fill_ref_dir' Victoria Dye via GitGitGadget
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=xmqqa5sr1x3p.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ps@pks.im \
--cc=vdye@github.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).