zsh-users
 help / color / mirror / code / Atom feed
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] )) ||


  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).