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@xxxxxxxxx> wrote: >> William Blevins <wblevins001@xxxxxxxxx> writes: >> >>> What is totally unexpected.... is the most simple search for ABC-1... >>> ``` >>> $ git ls-remote --heads git@xxxxxxxxxx: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.
