Re: git worktree add /foo <TAB>

[Oliver Kiddle <okiddle@yahoo.co.uk>]

On 9 Aug, Daniel Shahaf wrote:
> The second argument to 'git worktree add' can be any committish.  That
> committish becomes HEAD of the new worktree, and if it's a branch name,
> then that branch becomes the current branch of the new worktree, else
> the new worktree starts as a detached HEAD.
>
> How should that be completed?
>
> Currently it's completed as follows:
>
> +++ b/Completion/Unix/Command/_git
> @@ -2026,11 +2026,7 @@ _git-worktree() {
>        curcontext=${curcontext%:*}-$line[1]:
>        case $line[1] in
>          (add)
>  	  if (( $words[(I)--detach] )); then
>  	    args=( ':commit:__git_commits' )
>  	  else
>  	    args=( ':branch:__git_branch_names' )
>  	  fi

I can't remember why it was done this way but I'm wondering if the
two halves of the if…else…fi are the opposite way around from the
intention. Specifying --detach would be superfluous for anything but
a branch because it is the default for any other committish so after
--detach there is sense in only completing branches. I often apply logic
such as this but it might not always be helpful, such as if --detach
comes from an alias.

Otherwise, as you say, any committish is valid and our usual approach
is to just complete them all and expect user's to set tag-order to give
preference to the matches they find most useful. I suggested years back
that we perhaps add a mechanism for giving a default tag-order and
perhaps should consider it again.

> I see __git_recent_branches but it's not precisely what I have in mind.

What would be useful in this case?

Oliver