Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: git worktree add /foo <TAB>
- X-seq: zsh-workers 41552
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: git worktree add /foo <TAB>
- Date: Wed, 16 Aug 2017 11:37:29 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1502876260; bh=BsFY0fLmRUzg+KoB0IfDzOfgpd85ta8d9bEbZxjkLb8=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=bwHI5DU4ynGzdPe588mZ2vztE4NRHgR+PapasKmDN13ILF2Mb0+ekods0+r0BMY9XgQYA1fpicz+/n0AXqeM18jcHOqSdWrq9wYxHd/XZsZLkb5ThtwF4rpAOHO4y2z3ZVVD5ATMSMNq0ei22eSAH9Z2uxLvdSQVfVMV9eiH/W1nnXwk1UcH/yeBgT35NAbtEBVGIeZrQjlXNmM5SpcF0trh83E3jiZ0TJg91jV0w71tBnlDiRYn0w4P52ybAKZs7O3gANorMBeM6F2dpZSlq6M7WABL+JWM5hgGrZQzt4AYXvz+AVwwNnPAQwBMxtmAWSOKbwtrz0YDzMrhPSciqw==
- In-reply-to: <20170816042617.lud425bn2ycahy5d@tarpaulin.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20170809193113.3gjq3ezigb6yvdu4@tarpaulin.shahaf.local2> <15766.1502711853@thecus.kiddle.eu> <20170816042617.lud425bn2ycahy5d@tarpaulin.shahaf.local2>
Daniel Shahaf wrote:
> > 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.
> +1
> > I often apply logic such as this but it might not always be helpful,
> > such as if --detach comes from an alias.
> I don't understand. Firstly, both zsh aliases and git aliases are
> 'seen through' in completion; secondly, the perfect shouldn't be the
> enemy of the good.
If --detach comes from an alias, the user didn't go to the effort of
typing it. So there's a higher chance of the user wanting the
pedantically correct (or perfect) behaviour of completing all commits
rather than our too clever by half (or good) behaviour. However, I tend
to find that cutting down the number of completion matches where
possible is nearly always helpful.
> > 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.
>
> Let's collect a few such settings before we invent a mechanism; it's
> easier to invent when there are concrete details to work with.
Fair enough. I don't have any tag or group ordering styles for git
myself though I may have been put off trying on a couple of occasions
due to nested tag loops making it not entirely trivial.
> So, yes, reversing the if and adding a tag-order/group-order style
> should suffice.
Ok, patch below reverses the if.
> Additionally, it would be nice if the group description said
> "(alternatively specify name of new branch)" like _mkdir does.
Doesn't it need -b to create a new branch?
In such cases, compadd -x should be used for explanations instead of -X.
Oliver
diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 518e6d198..26554de05 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -2027,9 +2027,9 @@ _git-worktree() {
case $line[1] in
(add)
if (( $words[(I)--detach] )); then
- args=( ':commit:__git_commits' )
- else
args=( ':branch:__git_branch_names' )
+ else
+ args=( ':commit:__git_commits' )
fi
_arguments \
'(-f --force)'{-f,--force}'[checkout branch even if already checked out in another worktree]' \
Messages sorted by:
Reverse Date,
Date,
Thread,
Author