Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include fetched remote branches in git custom-completions #406

Open
sgasse opened this issue Mar 12, 2023 · 4 comments
Open

Include fetched remote branches in git custom-completions #406

sgasse opened this issue Mar 12, 2023 · 4 comments

Comments

@sgasse
Copy link
Contributor

sgasse commented Mar 12, 2023

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.

sgasse added a commit to sgasse/nu_scripts that referenced this issue Mar 12, 2023
This commit adds remote branches (e.g. origin/main, github/feature-a
etc.) to the output of the helper command `nu-complete git switchable
branches`.

Addresses nushell#406
sgasse added a commit to sgasse/nu_scripts that referenced this issue Mar 12, 2023
This commit adds remote branches (e.g. origin/main, github/feature-a
etc.) to the output of the helper command `nu-complete git switchable
branches`.

Addresses nushell#406
@fdncred
Copy link
Collaborator

fdncred commented Mar 13, 2023

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

sgasse added a commit to sgasse/nu_scripts that referenced this issue Mar 16, 2023
This commit adds an extra completion command which includes remote
branches with prefixes such as `origin/main`, `upstream/feature-a` etc.

We need to differentiate which command accepts which completion.

Addresses nushell#406
sgasse added a commit to sgasse/nu_scripts that referenced this issue Mar 27, 2023
The different commands such as `git checkout`, `git switch`, `git
cherry-pick` and `git rebase` all accept slightly differing refspecs.
This commit separates the extraction of refspecs and combines them in
individual completion commands for the different external commands.

All git commands complete with a table of `value | description` now.

Addresses nushell#406
sgasse added a commit to sgasse/nu_scripts that referenced this issue Mar 27, 2023
The different commands such as `git checkout`, `git switch`, `git
cherry-pick` and `git rebase` all accept slightly differing refspecs.
This commit separates the extraction of refspecs and combines them in
individual completion commands for the different external commands.

All git commands complete with a table of `value | description` now.

Addresses nushell#406
fdncred pushed a commit that referenced this issue Mar 29, 2023
The different commands such as `git checkout`, `git switch`, `git
cherry-pick` and `git rebase` all accept slightly differing refspecs.
This commit separates the extraction of refspecs and combines them in
individual completion commands for the different external commands.

All git commands complete with a table of `value | description` now.

Addresses #406

Co-authored-by: Simon Gasse <[email protected]>
@oatovar
Copy link

oatovar commented May 3, 2023

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
Copy link
Collaborator

fdncred commented May 3, 2023

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
Copy link

oatovar commented Jun 16, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants