Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62830 - [git] Install the project's zsh completion

Attached to Project: Arch Linux
Opened by Felipe Contreras (felipec) - Thursday, 06 June 2019, 19:58 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 22 July 2019, 02:44 GMT
Task Type Feature Request
Category Packages: Extra
Status Assigned
Assigned To Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


It would be nice if the package distributed the official completions for zsh:

# zsh completion
mkdir -p "$pkgdir"/usr/share/zsh/site-functions/
install -m 0644 ./contrib/completion/git-completion.zsh "$pkgdir"/usr/share/zsh/site-functions/_git

Most people would want these completions for several reasons:

1. They are blessed by Git developers
+ They are way faster
+ They are constantly up-to-date
+ They are developed by more people
+ They actually have tests; lost of them

There's only one drawback:

1. Not all the completions have help

I could go deeper and list many reasons why these completions are superior if anybody is interested.

But I think if all you need to do is look at the [tests for Git](, and then look at the tests for [Zsh](

If you need more reasoning, here's a list of testimonials:

* [Finally fed up with terribly slow auto-completion in zshell and starting looking a solution.](
* [Solved: ZSH tab completion painfully slow](
* [zsh git command auto-complete add extra origin to the git branch name](
* [ZSH tab completion of git commands is very slow. How can I turn it off?](

Disclaimer: I've been working on these for several years, so I'm slightly biased.
This task depends upon

Comment by Felipe Contreras (felipec) - Thursday, 06 June 2019, 20:00 GMT
Sorry about the format, I thought there was markup.
Comment by Christian Hesse (eworm) - Monday, 22 July 2019, 15:38 GMT
At the same time we should remove the completion files for git from zsh, no?
Comment by 이찬규 (ycg1221) - Friday, 06 December 2019, 07:34 GMT
As far as I can see, git completion from the zsh itself is more complete and up-to-date with more options included. Some part of it is just not released yet, but still reflects more recent version of the git than the completion included in the git package. That from git doesn't get updated accordingly with its version. Also I don't see any noticeable performance hit from my side.
Comment by 이찬규 (ycg1221) - Friday, 06 December 2019, 07:56 GMT
That testcase you linked is only for bash completion.
Comment by thayne (ender4) - Monday, 27 January 2020, 08:22 GMT
from what I can tell zsh completion packaged with git is just a wrapper around the bash completion, and as such doesn't have many of zsh completion's special features. And if users do prefer git's completion, they have the option of using the /usr/share/git/completion/git-completion.zsh file that is distributed with git. However, the git completion distributed with zsh _is_ out of date. Notably, it is missing completion for the new switch and restore commands. I wonder if it would make sense to update zsh completions more frequently than the rest of the zsh package, since software that the completions are for can update more frequently than zsh itself. Maybe split zsh core completions out into a separate package?
Comment by Felipe Contreras (felipec) - Saturday, 29 February 2020, 02:09 GMT
@ycg1221 No, it's actually the other way around. The git version is *always* more up-to-date than the zsh version. As I already said.

Also. The git version is blessed by git developers. It's much faster and reliable than the zsh version.

The completion files from zsh should not be removed, in case the user prefers that version.

@ender4 Yes, some features of the zsh completion are not present, but it does have the most important feature: it's actually usable.

The zsh completion for git is so slow that you can google 'zsh completion git slow' and you will have tons of people looking for a way to make them faster. The zsh project is not interested in making their completion usable.

That's why projects like oh-my-zsh have plugins like 'gitfast' which do use the git completions which I helped to create.

The issue you mentioned about missing commands would always work with the git completions, since they use the helper `git --list-cmds=`, so as soon as a new command is introduced it will show up in the completions. Not to mention that the completions would be synchronized with the git version, since it's they the ones that provide them.
Comment by 이찬규 (ycg1221) - Monday, 02 March 2020, 00:50 GMT
@felipec Well, as I vaguely mentioned I was talking about unreleased development version of zsh. And on the last month it was released, so actually zsh version is more up to date than git version now. git version is still out-of-date and untouched for months living it out-of-sync with features from the latest git release. Commit history also shows that it is not very activley maintained.
Comment by Felipe Contreras (felipec) - Monday, 31 May 2021, 23:09 GMT
That isn't true.

The zsh completion is updated the *exact moment* the git developers update the bash completion, because the former uses the latter.

Show me one command completion that is out of date.
Comment by Eli Schwartz (eschwartz) - Monday, 31 May 2021, 23:59 GMT
> git version is still out-of-date and untouched for months living it out-of-sync with features from the latest git release

Since you're so confident in this information, I'm sure you can tell us all which features these are???

> Commit history also shows that it is not very activley maintained.

Looking at /usr/share/git/completion/git-completion.zsh it seems to use a mixture of sourcing and using the bash completions, and decorating top-level options/subcommands with descriptions. So I'd expect *by design* it would get updated relatively rarely. How often are new git subcommands added? Why do you feel the need for it to be updated frequently?

Again, as per the OP's original report it must be automatically assumed the git-completion.zsh is at least as functional as the bash version, for feature parity, although indeed it probably doesn't always list out help text. Perhaps this help text is the "out-of-sync" thing you're referring to?

But then we're still back to the OP's original point, which claims:

- users are better served by getting the project's own bash completions available in git, rather than relying on third-party completions that don't get updated at all with new git versions (but may get updated independently and on a different schedule). Saying "oh, it's in unreleased zsh"

- "the zsh project has inferior, buggy completions for git", which appears to be a genuine complaint held by various people and definitely merits trying to decide if we'd prefer the official completions.
Comment by Eli Schwartz (eschwartz) - Tuesday, 01 June 2021, 00:08 GMT
My $0.02

As a general rule of thumb I think we try to rely on official project completions over unofficial collections from zsh/zsh-completions, or bash-completions, precisely because they sync better with the currently installed version and because the entire idea of completion collections providing something rather than the actual project, is... an incredible hack to support shell-completing in cases where the project itself isn't motivated or available to provide official ones.

This wouldn't exactly be the first time we rm a completion because it conflicts with the preferred completion provided by the actual project e.g. git.

For example, from bash-completion we remove slackware's "makepkg" completion. And periodically if a project gets completions we remove them from the completions packages while waiting for them to be removed upstream in favor of the official ones.
Comment by Felipe Contreras (felipec) - Tuesday, 01 June 2021, 00:35 GMT
Allow me to demonstrate how it works.

When you type `git switch --<tab>` zsh calls _git, that calls __git_zsh_main, that eventually finds the corresponding bash function: _git_switch.

Then, inside git-completion.bash, _git_switch calls `__gitcomp_builtin switch`, that calls `git switch --git-completion-helper`.

When you call that (inside a git repo) you get an output like:

--create= --force-create= --guess --discard-changes --quiet --recurse-submodules --progress --merge ...

That is what you see when you type `git switch --<tab>`.

So say git developers add a new option to `git switch`: --new (there's talk about doing that). You *immediately* get both bash and zsh completions updated without any modification to any of the two files (git-completion.bash or git-completion.zsh).

That's because git's option parser functionality has completions in mind.

Now grep `--git-completion-helper` in the official zsh completions for git, and you won't find anything. The zsh developers don't make use of this functionality, they must manually add each and every new option.

Yes, you lose the descriptions with git's zsh wrapper, but that's exactly what you get when you use bash, so it's not that bad.

Each approach has advantages and disadvantages, but git.git developers fine-tune the bash completions as they mostly use bash, and the ones that use zsh would rather use the wrapper to get as close as the bash completions as possible.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.