Include fetched remote branches in git custom-completions

[sgasse]

Often enough, I run something like git rebase --onto origin/main 7fla28h or git switch origin/my_colleagues_feature. For this, it would be helpful that the custom-completions for git included not only local branches but also the fetched branches from remotes.

I tested it out and the PR would be a small change. Do you agree or is there another reason why remote branches are excluded? If they are always shown after the local branches, it should also not distract too much.

[fdncred]

As long as this works as you describe above, i think we'll be cool. I just commented on the PR.

[oatovar]

Hello, I just noticed today that this has made my completions extremely slow on a large repository that I work on. At any given time, there are hundreds of remote branches.

git branch -r | lines | length
14557

Would it be okay if we adjusted this to respect an opt-out variable? The git bash completions have some variables to configure similar behavior, and I think something like that may work in this case. For example, a variable like GIT_COMPLETION_IGNORE_REMOTE_BRANCHES could control whether the remote branch completions are computed.

[fdncred]

sure, just put some comments around what you're changing so your changes aren't lost by the next person who wants to change them.

[oatovar]

Sorry for the delay on the performance work for large repos. I was tinkering with the script and discovered that this was a lot harder than I initially thought. I did however, find something that I think might be beneficial to others. While thinking through a solution, I was trying to concurrently run different tasks using par-each. Unfortunately, the tasks require different inputs and perform different actions, so I wasn't able to do:

$in | par-each { |it| # ... }

What came to mind recently however, was that I could create an array of closures and have par-each execute do on each closure instead.

[
  { $a | par-each { |it| $it + 1 } },
  { $b | par-each { |it| $it + 2 } }
] | par-each { |c| do $c }

I have yet to test this out with live data, but I'm hopeful that this pattern can help in situations like these. I know Hack isn't a very popular language, but one thing that I do miss about it is the concurrent functionality which the above technique mimics.