Improve stg-rebase completion to list available branches #102
Comments
|
It would be straightforward to make the completion options either stgit-enabled branches or all git branches by using either I.e.: _stg-rebase() {
__stg_add_args_help
__stg_add_args_merged
subcmd_args+=(
'(-n --nopush)'{-n,--nopush}'[do not push patches after rebasing]'
':new-base-id:__stg_branch_stgit'
)
_arguments -s -S $subcmd_args
}But that is much less full-featured than the set of options provided by the zsh completions for I personally almost never use |
Interesting, why not? I use |
|
When I pull from a remote repo, I use I am similarly interested in workflows where |
I sometimes manually verify what I am about to rebase on top of, for example in the case of some more-live-than-your-average-bear app plugin situations, where running head first into a merge conflict that might take a while to look into, might be uncomfortable. So I |
|
@jpgrayson I’ve tried to apply your suggestion, with it works well, and I think the only missing pieces are branches of remotes (e.g., Edit: The following change basically gives me what I want: diff --git a/completion/stgit.zsh b/completion/stgit.zsh
index a36bd06..ee931be 100644
--- a/completion/stgit.zsh
+++ b/completion/stgit.zsh
@@ -388,7 +388,7 @@ _stg-rebase() {
__stg_add_args_merged
subcmd_args+=(
'(-n --nopush)'{-n,--nopush}'[do not push patches after rebasing]'
- ':new-base-id:'
+ ':new-base-id:__stg_branch_all'
)
_arguments -s -S $subcmd_args
}
@@ -643,7 +643,8 @@ __stg_add_args_sign() {
__stg_branch_all() {
declare -a all_branches
all_branches=(
- ${${(f)"$(_call_program remote-branch-refs git for-each-ref --format='"%(refname)"' refs/heads 2>/dev/null)"}#refs/heads/}
+ ${${(f)"$(_call_program remote-branch-refs git branch 2>/dev/null | sed -e 's/^. //')"}#refs/heads/}
+ ${${(f)"$(_call_program remote-branch-refs git branch -r 2>/dev/null | sed -e 's/^. //')"}#refs/heads/}
)
local expl
_wanted -V branches expl "branch" compadd $all_branchesEdit: Actually, not exactly, the proposal are poluted with unwanted entries like |
|
As far as I can tell, the current stg 2.0 has a regression compared to stg 1.x wrt. |
Yes? Here is an example of the completions I get: Could you elaborate on the behaviors you are seeing versus what you're expecting, @lthms? |
|
|
|
I'd really like to understand why changing the completions script name had the ostensible effect on your system before we merge #226. On my system, zsh ships with its own old/defunct StGit completions. Those are installed at:
And the completion script that ships with StGit should nominally be installed to:
or, if doing a manual install:
This works on my system and should work on any system where It is more conventional for the completion script to have the same name as the executable it provides completions for (with a leading '_'), so there is nothing about So, some things to check in your environment:
|
|
Actually, Considering It’s manipulated in my Maybe, contrary to As far as I can tell, there is not Question, out of the blue: does the fact that the function has a different name than the file (the function is |
No, prepending is correct. The paths defined first have priority over those defined later, like
No, I don't think so. The One thing that has tripped me up in the past when dealing with zsh completion scripts is the method of starting a new zsh session to account for changed/added/removed completion scripts. The approach of running I wonder if it is possible that your zsh environment was not being reset fully or correctly after the renaming |
|
Though I only reported recently, I’ve had this issue for several weeks (probably since I’ve installed the rust based version of Stacked Git). There have been many full reboots involved. 😅 Not sure what we can do about this. At least I’m glad that I have found a way to have it work! But it may very well be that the issue is totally in my setup, especially since nobody else has complained about a similar problem. Feel free to close my PR if you think it is wiser! |
|
I am going to close this issue and the PR since I believe this problem to be peculiar to your environment. One parting thought: is your |
The completion of
stg rebasecould be improved, notable by listing the branches available for rebasing against. As of now, when I want to usestg rebase, I end up writinggit rebase, select the branch thanks to the completion utility ofgit, then changesgitforstg:).I am not really familiar with zsh completion framework, but I will definitely have a look at some point. In the meantime, opening this issue in case something more fluent than me wants to give it a try.
The text was updated successfully, but these errors were encountered: