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

From: Philip Oakley <philipoakley@iee.email>
Date: Feb 8, 2023, 14:51 UTC
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

Show 17 quoted lines

>
> 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.