__git_recent_commits cannot be called twice Re: [PATCH 2/5] _git: Offer @~$n as completion of recent commits.

[Daniel Shahaf <d.s@daniel.shahaf.name>]

Daniel Shahaf wrote on Sun, Oct 25, 2015 at 18:34:58 +0000:
> Suggested-by: Oliver Kiddle (users/20705)
> ---
> Output after the first two patches:
> 
> % git commit --fixup=<TAB>
> ed49c5f  @~0   - [HEAD]    _git: Offer @~$n as completion of recent commits. (2 minutes ago)
> ⋮
> 2685bbc  @~6   - [HEAD~6]  Merge branch 'master' of git://git.code.sf.net/p/zsh/code (15 hours ago)
> 506d592  @~7   - [HEAD~7]  36943: restore scan for reclaimable blocks in freeheap() (15 hours ago)
> e3c6845        - [e3c6845] unposted: _beep completion: Actually hook it for the 'beep' command. (15 hours ago)
> 779b311        - [779b311] 36913 + 36945: vcs_info quilt: Pass patch subject lines to gen-applied-string (15 hours ago)
> c62db9e        - [c62db9e] 36912: vcs_info quilt: Tolerate being in child of .pc's parent (15 hours ago)
> 272119b  @~8   - [HEAD~8]  unposted: small typo again (16 hours ago)
> c8c42d6  @~9   - [HEAD~9]  unposted: small typo (16 hours ago)

The new output works fine in 'git commit --fixup=<TAB>', but not in 'git
show <TAB>'.  This is because the latter calls __git_recent_commits via
two distinct codepaths.  Here's a minimal example:

     1	% autoload -Uz compinit
     2	% compinit
     3	% git <TAB><Esc>
     4	% cd $(mktemp -d)
     5	% git init && git commit -mm --allow-empty
     6	Initialized empty Git repository in /tmp/tmp.Y5qmiIcfSX/.git/
     7	[master (root-commit) 9b99116] m
     8	% _f() { repeat 1 __git_recent_commits }
     9	% compdef _f f
  ✓ 10	% f <TAB>
    11	HEAD                                                                       master
    12	9b99116  @~0  -- [HEAD]    m (4 seconds ago)
    13	% _f() { repeat 2 __git_recent_commits }
    14	% compdef _f f
  ✗ 15	% f <TAB>
    16	HEAD                                                                 master
    17	9b99116
    18	@~0
    19	-- [HEAD]    m (25 seconds ago)
    20	9b99116
    21	@~0
    22	-- [HEAD]    m (25 seconds ago)

A workaround is to disable the list-grouped style:

    23	% zstyle :completion::complete:f::commits list-grouped false
  ✓ 24	% f <TAB>
    25	HEAD    master
    26	@~0      -- [HEAD]    m (71 seconds ago)
    27	5d97266  -- [HEAD]    m (71 seconds ago)

This is only a workaround because grouping @~0 and 5d97266 is desirable,
since they both refer to the same commit.

I can't fix this issue properly right now, so I'll revert 36959 until
a fix can be made:

diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index ad1037e..dc9c296 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -5696,7 +5696,10 @@ __git_recent_commits () {
       else
         label="[HEAD~$distance_from_head]"
       fi
-      descr+=("@~${distance_from_head}":"${label} $k") # CROSSREF: use the same label as below
+      ## Disabled because _describe renders the output unhelpfuly when this function
+      ## is called twice during a single completion operation, and list-grouped is
+      ## in its default setting (enabled).
+      #descr+=("@~${distance_from_head}":"${label} $k") # CROSSREF: use the same label as below
 
       # Prepare for the next first-parent-ancestry commit.
       (( ++distance_from_head ))

The underlying problematic behaviour is reproducible without _git:

     1	$ zsh -f
     2	% _f() { local -a x=(foo:aaa bar:aaa);  repeat 2 _describe -tt 'desc' x }
     3	% compdef _f f
     4	% f
     5	bar
     6	foo
     7	-- aaa
     8	bar
     9	foo
    10	-- aaa

Basically, __git_recent_commits should disable the "Print descriptions one per line,
above the candidate completion" behaviour of _describe (which, IIRC, is
ultimately implemented by the "-E" flag passed to compadd from the 'case
CRT_EXPL' block in bin_compdescribe().)

Help with any of this will be welcome.

Daniel