From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Zsh Users' List <zsh-users@zsh.org>
Subject: Re: tag-order with git refs
Date: Thu, 08 Oct 2015 00:22:31 +0200 [thread overview]
Message-ID: <28911.1444256551@thecus.kiddle.eu> (raw)
In-Reply-To: <20151007120820.6f8a59e9@pwslap01u.europe.root.pri>
Peter wrote:
> How do I limit completion after "git checkout" to showing local heads
> first (i.e. branches I actually use)?
>
> zstyle ':completion:*:complete:git-checkout:*' tag-order heads-local
There are several nested tag loops in _git. In such cases, I find it
works better to list all tags along the path:
zstyle ':completion:*:complete:git-checkout:*' tag-order 'tree-ishs heads heads-local'
This has limitations. _next_tags will advance within inner tag loops
first before tracking back to outer ones. There are other irritations here
like ORIG_HEAD making it hard to complete origin/ given case-insensitive
matching control.
It also doesn't help that in a couple of cases functions are called
sequentially instead of using _alternative. The following patch helps a
tiny bit with this.
The tag loop structure for git checkout looks something like the
following:
tree-ishs
heads - sequentially calls:
heads-local
heads-remote
commit-tags
commit-tags
commit-objects - sequentially calls:
commit-tags
heads
commits
modified-files
modified-files
remote branches - the space looks like a mistake
remote-branch-names-noprefix
In general, it is better to avoid nesting. If you look at many of the
simpler functions in Completion/Unix/Type, you'll see that they don't
call _wanted but just use _description. This is sensible for functions
that are likely always called from another tag loop. It'd be worth
thinking about how we might further flatten this. Maybe _alternative
could take a special action style for functions that call a nested
_alternative that should be incorporated as a single tag loop.
I've not done anything about the lack of a tag loop in
__git_recent_commits because that looks like it needs wider refactoring.
On the subject of that function, I'd prefer if it used things like
HEAD~3 (or even @~3 which is an abbreviation for the same thing) instead
of the hashes for the matches. That gives them a common prefix so you
can type git checkout @<tab> if you know you want recent commits.
Looking at the history, it seems those were added to the description to
avoid grouping of matches if two commits have the same comment. I'd be
inclined to not use _describe and handle the descriptions more manually.
Also __git_heads should avoid duplicating local heads in the remote list.
Oliver
diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 1fcde90..2cfe636 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -457,7 +457,7 @@ _git-checkout () {
if (( CURRENT == 1 )) && [[ -z $opt_args[(I)--] ]]; then
# TODO: Allow A...B
local branch_arg='' \
- remote_branch_noprefix_arg='remote branches::__git_remote_branch_names_noprefix' \
+ remote_branch_noprefix_arg='remote-branches::__git_remote_branch_names_noprefix' \
tree_ish_arg='tree-ishs::__git_tree_ishs' \
file_arg='modified-files::__git_modified_files'
@@ -5587,8 +5587,9 @@ __git_commits () {
(( $+functions[__git_heads] )) ||
__git_heads () {
- __git_heads_local
- __git_heads_remote
+ _alternative \
+ 'heads-local::__git_heads_local' \
+ 'heads-remote::__git_heads_remote'
}
(( $+functions[__git_heads_local] )) ||
next prev parent reply other threads:[~2015-10-07 22:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 11:08 Peter Stephenson
2015-10-07 13:01 ` Mikael Magnusson
2015-10-07 13:24 ` Peter Stephenson
2015-10-07 19:06 ` Bart Schaefer
2015-10-07 22:22 ` Oliver Kiddle [this message]
2015-10-08 3:50 ` Bart Schaefer
2015-10-08 9:39 ` Peter Stephenson
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=28911.1444256551@thecus.kiddle.eu \
--to=okiddle@yahoo.co.uk \
--cc=zsh-users@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).