custom-completions: git: Include remote branches

[sgasse]

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 #406

[fdncred]

I'm a little worried about this because the regexes are so radically different. Will this get remote branches too? I wonder since the nu-complete git remotes part was removed. I haven't test it myself.

[sgasse]

Thanks for asking again @fdncred 🙂 - turns out there was a subtle difference in the output which I found while writing an explanation. Actually, I think we need different completions for git switch and e.g. git rebase --onto. Here is the output of three different completion commands in the latest version:

/home/simon/workspace/nu_scripts〉nu-complete git branches                                                              03/16/2023 08:54:07 
╭───┬────────────────────────────────╮
│ 0 │ feature/git_rebase             │
│ 1 │ feature/remote_in_git_branches │
│ 2 │ main                           │
╰───┴────────────────────────────────╯
/home/simon/workspace/nu_scripts〉nu-complete git switchable branches                                                   03/16/2023 08:54:13 
╭───┬────────────────────────────────╮
│ 0 │ feature/git_rebase             │
│ 1 │ feature/remote_in_git_branches │
│ 2 │ main                           │
│ 3 │ fix-since-last                 │
╰───┴────────────────────────────────╯
/home/simon/workspace/nu_scripts〉nu-complete git local and remote branches                                             03/16/2023 08:54:22 
╭───┬───────────────────────────────────────╮
│ 0 │ feature/git_rebase                    │
│ 1 │ feature/remote_in_git_branches        │
│ 2 │ main                                  │
│ 3 │ origin/main                           │
│ 4 │ origin/feature/git_rebase             │
│ 5 │ origin/feature/remote_in_git_branches │
│ 6 │ upstream/fix-since-last               │
│ 7 │ upstream/main                         │
╰───┴───────────────────────────────────────╯

Here are some differences:

• The remote upsteam has a branch called fix-since-last. Running git switch fix-since-last is a valid command and will create a local branch fix-since-last from upstream/fix-since-last and switch to it.
• Trying to run e.g. git rebase --onto fix-since-last 2024d529 will throw an error because the local branch fix-since-last does not exist.
• Rebasing on a remote branch with prefix which does not exist locally is totally fine, e.g. git rebase --onto upstream/main 2024d529 is a very usual command.
• Trying to switch to a remote branch with git switch upstream/main throws an error because it would require the --detach flag.
• git checkout upstream/main is fine.

I added the completion command now separately instead of replacing the "switchable branches" and updated the argument completions accordingly. Does it make sense like this?

[sgasse]

What do we do here? Add yet another completion command or concatenate the output of two and make it unique?
The below commands are all valid

• git checkout local-branch
• git checkout remote-branch-without-prefix
• git checkout upstream/remote-branch-without-prefix
• git checkout 234commit456hash

[fdncred]

Maybe I'm wrong here, but I'm thinking we'd concatenate and unique the list.

[sgasse]

OK that would work 👍 One further question: Should the completion suggestions be a flat list (as in the current version of git switch) or a table with value/description pairs? The flat list makes better use of limited terminal space, but especially commit suggestions may be useless without any description alongside.

[fdncred]

Could you maybe use a parameter to allow one to choose --verbose to show the value/description version?

[sgasse]

Hm but how exactly would that work? A parameter to using the completion, or a parameter in the git command? 🤔

[fdncred]

Thanks for the thorough explanation @sgasse.

[sgasse]

Hi, sorry for the wait - I was busy with some stuff. Took another stab at it and I think it makes sense to separate the individual completion parts into different functions. Here are five different parts:

1. Local branches
2. Remote branches without prefix that do not exist locally (e.g. feature-a derived from origin/feature-a)
3. Remote branches with prefix (e.g. upstream/feature-b)
4. Commits of the current branch
5. All commits known to the local git repo

Here is who accepts what:

• git checkout: 1,2,3,4,5
• git switch: 1,2
• git cherry-pick: 4,5
• git rebase (--onto): 1,3,4,5

I personally would never need 5 (all commits) in git rebase and would prefer to yield only 4 (the commits of the current branch as cut-off point), but restricting it would not be completely right.

I also saw that there were some changes and rebased on them updating namings where needed. Could you take another look at how you like it @fdncred ? Below are screenshots of how it looks on the current version.

[fdncred]

LGTM. Thanks for the changes.