tag-order with git refs

tag-order with git refs

[Peter Stephenson]

Things that have been bugging me for ages but I never dared ask
about...

Notionally this is a user question, though I suspect it's soon going to
drift down the implementation.

How do I limit completion after "git checkout" to showing local heads
first (i.e. branches I actually use)?

If you can demonstrably get this to work (please don't waste time
posting untried solutions), feel free to give tne answer and ignore the
following.

From the output of ^xh it should be something like

zstyle ':completion:*:complete:git-checkout:*' tag-order heads-local

and certainly the look-up of the style and context appears to be
working.  But the match against the actual tag doesn't work (proved by
adding "-" to the end, which gives me no matches at all).

The manual implies patterns should work as tags (i.e. values of the
tag-order style) but I'm getting bizarre results --- e,g '[a-z]*' gives
me everything, '[a-m]*' gives me nothing, '[n-z]*' gives me only options
and nothing else (all these with the "-" element appended for debugging
purposes).  Indeed, 'o*' gives me options.  However, '[a-np-z]*' gives
all the matches (other than options) I expect.  Further playing suggests
patterns are just not working how I expect.  Not that I'm particularly
interested in patterns, I'm just trying to narrow down the tags by hook
or by crook and failing dismally.

This is related to stuff down in the bowels where it calls "comptry -m
tag", so I'm unlikely to be able to get to the bottom of this in a
finite lifetime.

pws

Re: tag-order with git refs

[Mikael Magnusson]

On Wed, Oct 7, 2015 at 1:08 PM, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> Things that have been bugging me for ages but I never dared ask
> about...
>
> Notionally this is a user question, though I suspect it's soon going to
> drift down the implementation.
>
> How do I limit completion after "git checkout" to showing local heads
> first (i.e. branches I actually use)?
>
> If you can demonstrably get this to work (please don't waste time
> posting untried solutions), feel free to give tne answer and ignore the
> following.
>
> From the output of ^xh it should be something like
>
> zstyle ':completion:*:complete:git-checkout:*' tag-order heads-local

I get the same result as you; this has no effect. However,
zstyle ':completion:*:complete:git-checkout:*' group-order heads-local
does work. The question is a bit unclear, you can't limit something to
being shown first, but at least with group-order, if you don't mind
getting spammed with other results, just hitting tab a few times will
get you the branches you want first. Arguably this should be the
default order too, without having to muck around with custom styles.

-- 
Mikael Magnusson

Re: tag-order with git refs

[Peter Stephenson]

On Wed, 7 Oct 2015 15:01:27 +0200
Mikael Magnusson <mikachu@gmail.com> wrote:
> I get the same result as you; this has no effect. However,
> zstyle ':completion:*:complete:git-checkout:*' group-order heads-local
> does work.  The question is a bit unclear, you can't limit something to
> being shown first

I mean what tag-order is supposed to be for, preferring matches for
earlier tags if there are any ("shown" isn't the right word except in
so much as they are shown if you're listing).  If there are matches for
local heads, I want to see only these, so it doesn't go round the tag
loop to find other matches.  That's supposed to be fairly
straightforward to do.

There must be *something* special about the git competion that's
preventing it, though probably obscure and quite likely a side effect of
some completion "feature".  I can see this working with Perforce:

  zstyle ':completion:*:p4-*:at-suffix:*' tag-order changes '*'

correctly limits completion after

  p4 files Makefile@

to just changes applicable to Makefile and not, for example, labels ---
labels and changes mean something for present purposes pretty much like
tags and commits (don't write in if you're a Perforce expert :-)).
That's the general effect I'm after.

> but at least with group-order, if you don't mind
> getting spammed with other results

That's what I'm trying to avoid.  There are way too many other results
to make the listing remotely useful unless I limit it.  I'd like to
focus on getting that to work.  I already have grouping under headings
which is enough for visibility for the matches I do want.

pws

Re: tag-order with git refs

[Bart Schaefer]

On Oct 7,  2:24pm, Peter Stephenson wrote:
}
} I mean what tag-order is supposed to be for, preferring matches for
} earlier tags if there are any ("shown" isn't the right word except in
} so much as they are shown if you're listing).  If there are matches for
} local heads, I want to see only these, so it doesn't go round the tag
} loop to find other matches.  That's supposed to be fairly
} straightforward to do.

I think this comes down to the way __git_heads_local calls _wanted.  I
compared with a completion where tag-order works and one difference is
that there's nothing in a group named "heads-local" at the time comptags
is called.

Different sets of options are given different descriptions, so they get
broken out in the listing, but they're all put in the -default- group
as far as I can tell.

Maybe this is a bug downstream of _wanted, but instead of
  _wanted heads-local ...
one has to call
  _wanted heads-local:DESCRIPTION:ACTION ...
in order to cause _all_labels to pass a -J option to compadd and thereby
make tag-order work.

Or at least I think that's what's going on, I'll probably shortly be
proved wrong.

Re: tag-order with git refs

[Oliver Kiddle]

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

Re: tag-order with git refs

[Bart Schaefer]

On Oct 8, 12:22am, Oliver Kiddle wrote:
> Subject: Re: tag-order with git refs
>
> 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.
>  
>  (( $+functions[__git_heads] )) ||
>  __git_heads () {
> -  __git_heads_local
> -  __git_heads_remote
> +  _alternative \
> +    'heads-local::__git_heads_local' \
> +    'heads-remote::__git_heads_remote'
>  }

I think this will also end up passing TAG:DESCR:ACT (with empty DESCR)
down to _all_labels, which will take the "if" branch that adds the -J
option to compadd to make the tag a group name.

(time passes)

And indeed the patch does accomplish that, so now there is a group named
heads-local, but the style Peter thinks should work, still does not.

On the other hand, the style Oliver suggested with the list of "all tags
along the path" does exactly what Peter wants.  Oliver, can you explain
why?

Re: tag-order with git refs

[Peter Stephenson]

On Thu, 8 Oct 2015 00:22:31 +0200
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> 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'

Aha, that's already a good start.  I'm starting to see why the patterns
did bizarre things --- I wasn't banking on needing multiple tag matches
to get a single completion.

Sounds like there are at least some possibilities for improving this,
but I wonder if we can make ^xh a bit more helpful about what you
actually need to do in a particular case?  That would save a lot of
documentation for a lot of completions.  It's sort of mentioning the
right words but doesn't give any help about how you need to combine
them.  If we could make it build up a "story so far" string and output
it at the end, or something like that...?

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

And I'm getting completions for heads-remote, somehow (that's before
your patch, at least).  Oooh...

zstyle ':completion:*:complete:git-checkout:*' ignored-patterns '*/*'

With the _ignored completer that does something like what I want.

Thanks
pws