Re: Unexpected (bug-like) behavior in `git ls-remote` matching.

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I think the tail-matching behavior is not what we would probably choose
> today, but that is how it has behaved since 2005, and we are not going
> to break backwards compatibility in a plumbing tool like ls-remote.

The tail-matching behaviour that was Linus's preference (his
show-ref behaves the same way) has one interesting feature---looking
for all 'master' branches in different hierarchies is trivial.

In today's world, it would be tremendously benefitial if "ls-remote"
can trim not just the communication between the repositories but
also the enumeration of the ref namespace at the source repository
using the pattern, and tail-matching would not contribute to it at
all (unless if your server side adds special index).  If we used
prefix matching, our refs API can take advantage of it in reducing
the cost to enumerate refs, and on-the-wire protocol has ref-prefix
capability to help it.

> Likewise, something more elaborate like full-path globbing or even
> regex matching would be possible, but would need to be activated by an
> option.

True.  We should be able to do a bit better than just tail-matching
with an option.

I would not recommend sending over regex as protocol capability the
same way as ref-prefix works, unless we adopt something that can
match linear-time like re2 and use it everywhere, as you can send a
pattern that is deliberately made inefficient to inconvenience the
other side.

Thanks.