From: David Mandelberg Date: Mon, 03 Mar 2025 19:49:24 GMT Subject: Re: [PATCH 3/3] completion: fix bugs with slashes in remote names Message-ID: In-Reply-To: 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?