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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 8, 2023, 17:40 UTC
Message-ID: <xmqq357gt5s9.fsf@gitster.g>
In-Reply-To: <Y+POCxHMzrZj2bwz@coredump.intra.peff.net>

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.