On Mon, Dec 10, 2018 at 07:10:46AM -0800, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > The second non-option argument to `git worktree`'s `add` command is an > optional revision. Let's complete it. > > Inspired by https://github.com/git-for-windows/git/pull/1681. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- > contrib/completion/git-completion.bash | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 9e8ec95c3c..4194b4a2e7 100644 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -2773,6 +2773,11 @@ _git_worktree () > add,--*) > __gitcomp_builtin worktree_add > ;; > + add,*) > + if [ $(__git_count_arguments "worktree") -eq 2 ]; then > + __git_complete_refs > + fi > + ;; Unfortunately, this seems to work only in the following case: git worktree add path <TAB> i.e. when the two-be-completed word is still empty. However, git worktree add path m<TAB> doesn't work anymore, as it lists paths instead of refs. Furthermore, git worktree add --detach path <TAB> git worktree add --detach path m<TAB> git worktree add -b newbranch path <TAB> list paths as well. However, I presume unintentionally, git worktree add -b <TAB> does the right thing and lists refs, but with git worktree add -b m<TAB> we are back at paths instead of refs. OTOH, git worktree add --detach <TAB> git worktree add --lock <TAB> will erroneously list refs. I wrote a completion function for 'git worktree' a long while ago, back when it had only two subcommands, which did mostly the right thing, but I found it too convoluted for serious submission. Here it is for inspiration: https://public-inbox.org/git/1440190256-21794-1-git-send-email-szeder@xxxxxxxxxx/ > list,--*) > __gitcomp_builtin worktree_list > ;; > -- > gitgitgadget
