Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 27, 2018, 05:15 UTC
Message-ID: <20180227051555.GA65699@aiede.svl.corp.google.com>
In-Reply-To: <87inaje1uv.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

> On Sat, Feb 24 2018, Jeff King jotted:

Show 9 quoted lines

>> I actually wonder if we should just specify that the patterns must
>> _always_ be fully-qualified, but may end with a single "/*" to iterate
>> over wildcards. Or even simpler, that "refs/heads/foo" would find that
>> ref itself, and anything under it.
>
> I agree that this is a very good trade-off for now, but I think having
> an escape hatch makes sense. It looks like the protocol is implicitly
> extendible since another parameter could be added, but maybe having such
> a parameter from the get-go would make sense:

I prefer to rely on the implicit extensibility (following the general YAGNI principle).

In other words, we can introduce a pattern-type later and make the current pattern-type the default.

Thanks for looking to the future.

[...]

> E.g. if the refs were stored indexed using the method described at
> https://swtch.com/~rsc/regexp/regexp4.html tail matching becomes no less
> efficient than prefix matching, but a function of how many trigrams in
> your index match the pattern given.

I think the nearest planned change to ref storage is [1], which is still optimized for prefix matching. Longer term, maybe some day we'll want a secondary index that supports infix matching, or maybe we'll never need it. :)

Sincerely, Jonathan

[1] https://public-inbox.org/git/CAJo=hJsZcAM9sipdVr7TMD-FD2V2W6_pvMQ791EGCDsDkQ033w@mail.gmail.com/#t