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