On Tue, Jan 19, 2021 at 05:52:04PM -0500, Jeff King wrote: > On Tue, Jan 19, 2021 at 05:23:36PM -0500, Taylor Blau wrote: > > > > Having now looked carefully at the ls-refs code, it's a pure > > > prefix-match, too. So I think we _could_ rely on for_each_fullref_in() > > > returning us the correct full results, and not checking it further in > > > send_ref(). But I kind of like keeping it there as an extra check (and > > > one which could in theory grow more logic later). > > > > Hmm. What if the caller asks for: > > > > ref-prefix refs/tags/a > > ref-prefix refs/tags/b > > > > ? > > > > The LCP between those two is refs/tags, so send_ref() will presumably > > get lots of reuslts that it doesn't care about (assuming there are tags > > besides a and b). > > Oh, you're right, of course. Ignore me. :) Actually, I am not sure that we would look for "refs/tags/" in that case (I did a quick test and we do not seem to). Which makes sense, as it is cheaper to find the "a" and "b" hierarchies separately if there is a very big "refs/tags/c" hierarchy. But I agree that this is a good reason that callers should consider it as an optimization which could return more results than expected. -Peff
