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?
