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

From: Jeff King <peff@peff.net>
Date: Feb 8, 2023, 16:33 UTC
Message-ID: <Y+POvZLrtfm/qQwp@coredump.intra.peff.net>
In-Reply-To: <Y+POCxHMzrZj2bwz@coredump.intra.peff.net>

On Wed, Feb 08, 2023 at 11:30:04AM -0500, Jeff King wrote:

Show 17 quoted lines

> See commit 631f0f8c4b (ls-remote: do not send ref prefixes for patterns,
> 2018-10-31), which also adds a test. However, it was just handling
> existing behavior (which in fact confused another developer and caused a
> bug which the commit was fixing!).
> 
> 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.
> 
> There's some discussion in this thread about adding a new option to do
> prefix-matching, but I don't think any code was ever written:
> 
>   https://lore.kernel.org/git/m2k12g7v5u.fsf@gmail.com/
> 
> Likewise, something more elaborate like full-path globbing or even
> regex matching would be possible, but would need to be activated by an
> option.

Oh, and I forgot to mention: the documentation for ls-remote is quite weak here, and simply says "matching" without defining it. So the most obvious improvement is fixing that documentation to describe the current rules (which AFAIK is basically matching the pattern as a glob, but with an implicit "/" anchor, but somebody should double check the code before writing a documentation patch).

-Peff