On Wed, Mar 15, 2023 at 12:24:18PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > ... we may > > want some kind of "literal" mode, that takes in a list of refs rather > > than a list of patterns, and does a sorted-merge with the list of > > available refs (or uses a hash table, I guess, but for-each-ref also > > tries to avoid even being linear in the total number of refs, so you'd > > still want to find the lowest/highest to bound the iteration). > > Exactly. > > I actually was wondering if "literal" mode can just take a list of > <things>, and when a <thing> is not a refname, use it as if it > were. I.e. %(refname) would parrot it, while %(refname:short) would > not shorten and still parrot it, if the <thing> is 73876f4861c, but > something like %(subject) would still work. Yeah, I think that would nicely solve the quadratic issue _and_ the "we are stuck using only ref tips" issue. I like it. > For that, I suspect ref-filter.c::filter_refs() would need to learn > a different kind fo finter->kind that iterates over the literal > "refs" that was fed from the standard input, instead of calling > for_each_fullref_in() for the given hierarchy, but the new iterator > should be able to reuse the ref_filter_hander() for the heavy > lifting. Yeah, that sounds about right from my recollection of the code. I suspect there may be other sharp edges (e.g., asking for %(upstream) isn't meaningful for a non-ref). But softening those is actually something I think we want to do in the long run, as it helps with the long-term goal of sharing pretty-printing code between ref-filter, cat-file, and pretty.c. -Peff
