Thread (33 messages) flat view 33 messages, 4 authors, 2021-01-23

Re: [PATCH 2/2] ls-refs.c: traverse longest common ref prefix

From: Jeff King <hidden>
Date: 2021-01-20 00:10:23

On Tue, Jan 19, 2021 at 06:52:31PM -0500, Taylor Blau wrote:
quoted
I guess they require an explicit '*', but fundamentally it's the same
concept (and certainly they are not just single references).
Yeah, that is the point that I was trying to make. But re-reading this
patch after knowing that it confused you, I think the clearest way to
make that point is to drop that second paragraph entirely.
Sounds good.
quoted
Based on my other poking, I'm not entirely sure that we can return too
many results. But I do think it's worth keeping the caller more careful.
It can return more results, but I don't think that my writing in
b31e2680c4 is particularly clear. Here's an example, though. Say I ask
for `git for-each-refs 'refs/tags/a/*' 'refs/tags/a/b/c'`. The LCP of
that is definitely "refs/tags/a", which might traverse other stuff like
"refs/tags/a/b/d", which wouldn't get matched by either.
I thought that would be matched by refs/tags/a/*, but it looks like
for-each-ref treats "*" as matching only a single path component. So
really just:

  git for-each-ref refs/tags/*

requires extra filtering already. But AFAICT none of that is true for
ls-refs, which is strictly prefix matching already.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help