* git worktree add /foo <TAB>
@ 2017-08-09 19:31 Daniel Shahaf
2017-08-14 11:57 ` Oliver Kiddle
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Shahaf @ 2017-08-09 19:31 UTC (permalink / raw)
To: zsh-workers
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
… and while simply using __git_commits unconditionally wouldn't be
wrong, I think this case might prefer a variant of __git_commits that
offers branch names in preference to the N other things __git_commits
offers. Do we have such a helper?
(Or should I just add another tag-order style to my config...?)
I see __git_recent_branches but it's not precisely what I have in mind.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: git worktree add /foo <TAB>
2017-08-09 19:31 git worktree add /foo <TAB> Daniel Shahaf
@ 2017-08-14 11:57 ` Oliver Kiddle
2017-08-16 4:26 ` Daniel Shahaf
0 siblings, 1 reply; 4+ messages in thread
From: Oliver Kiddle @ 2017-08-14 11:57 UTC (permalink / raw)
To: Zsh workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: git worktree add /foo <TAB>
2017-08-14 11:57 ` Oliver Kiddle
@ 2017-08-16 4:26 ` Daniel Shahaf
2017-08-16 9:37 ` Oliver Kiddle
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Shahaf @ 2017-08-16 4:26 UTC (permalink / raw)
To: zsh-workers
Oliver Kiddle wrote on Mon, Aug 14, 2017 at 13:57:33 +0200:
> 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.
+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.
> 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.
To start with, here's one style I use:
# Prefer recent commit object name completion
zstyle ':completion::complete:git-(format-patch|send-email):argument-1:' group-order commits
> > I see __git_recent_branches but it's not precisely what I have in mind.
>
> What would be useful in this case?
Just __git_branch_names — namely, names of local branches — is exactly
what I was after. (Don't know how I managed to miss it)
So, yes, reversing the if and adding a tag-order/group-order style
should suffice.
Additionally, it would be nice if the group description said
"(alternatively specify name of new branch)" like _mkdir does.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: git worktree add /foo <TAB>
2017-08-16 4:26 ` Daniel Shahaf
@ 2017-08-16 9:37 ` Oliver Kiddle
0 siblings, 0 replies; 4+ messages in thread
From: Oliver Kiddle @ 2017-08-16 9:37 UTC (permalink / raw)
To: zsh-workers
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]' \
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-16 9:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-09 19:31 git worktree add /foo <TAB> Daniel Shahaf
2017-08-14 11:57 ` Oliver Kiddle
2017-08-16 4:26 ` Daniel Shahaf
2017-08-16 9:37 ` Oliver Kiddle
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).