On 02/26, Jonathan Nieder wrote: > Ævar Arnfjörð Bjarmason wrote: > > On Sat, Feb 24 2018, Jeff King jotted: > > >> 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. Yeah this is what I'm going to do for the next re-roll of the series, make the pattern matching simple and later we can extend it if we want since we already have the ability to add new features to commands (you can see how I added shallow to fetch for an example). > > 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@xxxxxxxxxxxxxx/#t -- Brandon Williams
