K Jayatheerth [off-list ref] writes:

Currently, git repo info relies on an all-or-nothing query model
where users must either know the exact, fully-qualified key name or use
the --all flag to dump the entire repository state.
As the number of supported keys expands, dumping all metadata and
relying on external filters like grep becomes an inefficient bottleneck
for a plumbing command.

Enable category-based prefix querying so users can request
entire groups of related keys natively

You mean "repo info" takes layout.bare and layout.shallow (right
now, later we may gain a lot more), so you want to say "everything
under 'layout' to grab these two values?

Why should we limit ourselves to "prefix match"?  Would a glob like
"layout.*", or "path.*.absolute", work better?  Especially the
latter, i.e., "I want the path variables, but am not interested in
their .relative values, only the .absolute ones."  It is especially
puzzling as you are going to do a dumb linear search in this mode
anyway.

Perhaps during each iteration of the loop over argv[], you can first
look for exact match using the existing bsearch() codepath.  If that
succeeds, you have a single key to return the value for.  If it does
not match exactly any key, use the new "prefix" (or "glob" which I
think would make far more sense) match codepath to find which key(s)
to return values for, so iterate over them (or say "Hey, that pattern
does not match any key!" and fail).