From: Philip Oakley <philipoakley@iee.email>
Date: Wed, 08 Feb 2023 14:51:09 GMT
Subject: Re: Unexpected (bug-like) behavior in `git ls-remote` matching.
Message-ID: <1e073897-162d-e1e6-bab2-b424b21e1015@iee.email>
In-Reply-To: <CALJHx12DetwZ=+aMEG6Ss4P3fMTeLN2styXuPw93C5N6yg98NA@mail.gmail.com>

On 08/02/2023 13:49, William Blevins wrote:
> This still feels "weird" to me. Other pattern matching tools like grep
> and sed don't have exceptions to their behavior like this.
>
> Can you reference the unit tests that verifies this specific behavior?

As someone who also trips up over the *nix command line, Is this a bash
(glob) expansion issue?
So there is a two step 'expansion', first by bash, and then by git's
pattern match. Even plain text could be "expanded" if there's a suitable
expansion

a quick search suggested
https://superuser.com/questions/861077/is-it-possible-to-print-out-the-shell-expansion
which has some tipe I wasn't aware of.

Philip

>
> On Wed, Feb 8, 2023 at 2:20 AM Junio C Hamano <gitster@pobox.com> wrote:
>> William Blevins <wblevins001@gmail.com> writes:
>>
>>> What is totally unexpected.... is the most simple search for ABC-1...
>>> ```
>>> $ git ls-remote --heads git@github.com:owner/repo.git ABC-1
>>> <ref>    refs/head/ABC-1
>>> <ref>    refs/head/feature/ABC-1
>>> ```
>> Sorry, but I cannot see what is surprising about the above.  If you
>> have these branches locally, you should also see these refs in the
>> output of "git show-ref ABC-1".  Refname hierarchies work just like
>> pathnames with directories, and without glob in the pattern, tail
>> matching that honors path component boundary is very much the norm
>> in the oldest part of Git, i.e. ABC-1 matches refs/heads/ABC-1 but
>> not refs/heads/XABC-1.