From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@zsh.org
Subject: Re: git worktree add /foo <TAB>
Date: Wed, 16 Aug 2017 11:37:29 +0200 [thread overview]
Message-ID: <21782.1502876249@thecus.kiddle.eu> (raw)
In-Reply-To: <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]' \
prev parent reply other threads:[~2017-08-16 9:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-09 19:31 Daniel Shahaf
2017-08-14 11:57 ` Oliver Kiddle
2017-08-16 4:26 ` Daniel Shahaf
2017-08-16 9:37 ` Oliver Kiddle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=21782.1502876249@thecus.kiddle.eu \
--to=okiddle@yahoo.co.uk \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).