Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [BUG] git checkout completion shows duplicated branch names



Marc Cornellà wrote on Mon, 24 Sep 2018 14:51 +0000:
> Steps to reproduce:
> 
> git init repo
> cd repo
> git commit --allow-empty -m 'Initial commit'
> git checkout -b topic/foo
> git checkout master
> 
> Now, when trying to complete to a branch name, here's what I see:
> 
> ~/repo% git checkout <TAB>
> e287376  -- [HEAD]    Initial commit (12 seconds ago)
> topic/foo  master  -- Initial commit
> HEAD                                                master
>                                  topic/foo
> 
> Notice that branches appear twice. This only happens on versions newer
> than 5.3.1, excluding this one.
> A `git bisect` pointed me to commit e869952, which changed to using
> the __git_recent_branches function,
> which uses extracts branch names from the git reflog.
> 

The catch here is that they appear as part of different groups: the
first instance is part of the "recent branches" group and the second is
part of the "head" group.  You can see group names by setting «zstyle
':completion:*' format '> %d'».  A user can disable or hide individual
groups with the tag-order style.  If a user disables the "recent
branches" group, then topic/foo should still be offered under "head",
and vice-versa.

That is not to say that we can't make changes; I am just trying to
explain that avoiding the duplication is not as trivial as it may seem.

> Furthermore, on versions prior to commit 4dddf3aa (< zsh-5.6), the
> completion is even worse since a branch
> is not fully completed even if there isn't any other branch with the
> same prefix.
> 
> So typing this:
> 
> ~/repo% git checkout topic/<TAB>
> topic/foo  -- Initial commit
> topic/foo
> 
> gets completed to `git checkout topic` instead of the full branch name.
> 

With 'zsh -f' + 'autoload compinit; compinit', «git checkout t<TAB>»
gives me «git checkout topic/foo<CURSOR>» and a subsequent <TAB>
displays possible completions.  That is better than the behaviour you
get, but I agree it shouldn't be treating this situation as an ambiguous
completion.  I don't know offhand where the relevant piece of code is,
though.  Probably in the internals of bin_compdescribe/bin_compadd?

Here's a minimal example:

_f() {
  local a=( foo:FOO bar:BAR ) expl
  _describe -t lorem "lorem" a
  _wanted ipsum expl 'ipsum' compadd foo bar
} 
compdef _f f
f f<TAB>

> So after version 5.6 and newer the bug is not that annoying because
> the full branch name is indeed completed,
> but there're still duplicated entries and I'd expect there to be
> unique branch names.
> 
> If I knew enough about the completion system I would try to fix it,
> but sometimes you have to let the hard stuff
> to the pros.

Cheers,

Daniel



Messages sorted by: Reverse Date, Date, Thread, Author