On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > Complete the paths of existing working trees for 'git worktree's > 'move', 'remove', 'lock', and 'unlock' subcommands. > [...] > Arguably 'git worktree unlock <TAB>' should only complete locked > working trees, but 'git worktree list --porcelain' doesn't indicate > which working trees are locked. So for now it will complete the paths > of all existing working trees, including non-locked ones as well. It is a long-standing To-Do[1] for "git worktree list [--porcelain]" to indicate whether a worktree is locked, prunable, etc. Looking at the implementation of builtin/worktree.c:show_worktree_porcelain(), it should be easy enough to add. (Adding it for the non-porcelain case would perhaps require more thinking and design since we might want a --verbose option to trigger the extra information.) [1]: https://public-inbox.org/git/CAPig+cTTrv2C7JLu1dr4+N8xo+7YQ+deiwLDA835wBGD6fhS1g@xxxxxxxxxxxxxx/ > Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> > --- > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > @@ -2981,10 +2981,21 @@ _git_whatchanged () > +__git_complete_worktree_paths () > +{ > + local IFS=$'\n' > + __gitcomp_nl "$(git worktree list --porcelain | > + sed -n -e '2,$ s/^worktree //p')" > +} I know that the commit message talks about it, but it might deserve an in-code comment here (or a function-level comment) explaining why the first line of "git worktree list --porcelain" output is thrown away since it's not necessarily obvious to the casual reader.
