On Tue, Jan 19, 2021 at 06:52:31PM -0500, Taylor Blau wrote: > > 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. > > 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
