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

From: Jeff King <peff@peff.net>
Date: Jan 20, 2021, 00:08 UTC
Message-ID: <YAd0kyBP8LRSEBYw@coredump.intra.peff.net>
In-Reply-To: <YAdwvzQCGc5TfXTF@nand.local>

On Tue, Jan 19, 2021 at 06:52:31PM -0500, Taylor Blau wrote:

Show 6 quoted lines

> > 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.

Show 8 quoted lines

> > 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