Re: [PATCH 3/3] completion: fix bugs with slashes in remote names

[David Mandelberg <david@mandelberg.org>]

Op 2025-03-03 om 14:33 schreef SZEDER Gábor:
> On Sun, Mar 02, 2025 at 03:34:07PM -0500, David Mandelberg wrote:
>> Good point, I hadn't thought of that. Do you have a rough estimate of what
>> "a lot of remotes" is? 100ish, maybe?
> 
> 5.
> 
> In Git for Windows fork()-ing subshells and fork()+exec()-ing
> processes is rather costly, about an order of magnitude slower than on
> Linux.  The rough equivalent of the body of your loop, with two
> subshells and a git process:
> 
>    time { a=$(echo 1) ; b=$(echo 2) ; git for-each-ref >/dev/null ; }
> 
> takes on average 0.17s on a windows box I have access to (with fully
> packed refs, and merely 4 refs in total).  So guess at about 4-5
> remotes it would take over a second to react to my TABs...

Oh wow, that's much slower than I expected, thanks for the numbers!

> I would rather try to go in the opposite direction to see whether 'git
> for-each-ref' could be taught to strip the "refs/remote/$remote/"
> prefix with a format specifier option like '%(refname:strip=remote)'.
> 
> That would surely be faster than any shell filtering we might come up
> with, and would also save us from the trouble of escaping glob and/or
> regex metacharacters for shell/sed pattern matching.

That doesn't fix the issue of needing to anchor the $cur_ part of the 
pattern after each refs/remote/$remote/ prefix. It might be possible to 
use something like %(refname:strip=remote) to find all remote branches 
with the remote stripped, then filter them for $cur_ in the shell or 
with sed though.

What are the expectations around mixing versions of git itself and files 
in contrib? Can a single patch series add a feature to for-each-ref and 
use it in git-completion.bash, or does the feature in for-each-ref need 
to exist for some time before git-completion.bash can use it?