git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 00/14] completion: a bunch of updates

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Nov 2, 2020, 20:18 UTC
Message-ID
<CAMP44s2bgZbKde-UFL7+sR-7QgEv5Oiho2LTi3RG7S4BD0iuaw@mail.gmail.com>
In-Reply-To
<xmqq361x7xj5.fsf@gitster.c.googlers.com>
On Thu, Oct 29, 2020 at 11:27 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 20 quoted lines
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> On zsh the situation is different; zsh by default has a git completion
> >> (/usr/share/zsh/functions/Completion/Unix/_git), and some might argue
> >> it's more complete than git's zsh completion,
> >
> > How is that completion script developed, maintained and distributed?
> >
> > By "by default" I believe you mean that it gets installed when you
> > install zsh automatically.  Is the situation different on macOS land
> > (which I can believe, unfortunately)?
> > ...
>
> Web searching for "zsh git autocompletion" gave a few interesting insights.
>
>  - https://medium.com/@oliverspryn/adding-git-completion-to-zsh-60f3b0e7ffbc
>    was the first hit, which is about how to use what we ship in contrib/

It's weird that he didn't have completion. He probably hadn't enabled completion (in general).

>  - https://stackoverflow.com/questions/24513873/ which was near the top
>    had these gems.
> The "knows out of the box" in https://stackoverflow.com/a/58517668
> is matches your "zsh by default has".
This is just the tip of the iceberg.

In the past people that wanted to have the Zsh default could do `brew install git --without-completions`, but the Homebrew team decided to remove that option, so now everyone gets the completions overridden by installing Git.

https://github.com/Homebrew/homebrew-core/commit/f710a1395f44224e4bcc3518ee9c13a0dc850be1
Show 15 quoted lines
> > so why would
> > distribution maintainers chose the one in 'contrib' (an unofficial
> > contributed script) over the official one? Indeed they don't, at least
> > on Arch Linux.
>
> You're right.  They would certainly not, and the situation is quite
> different from bash completion where we seem to be the authoritative
> implementation.
>
> This leads me in a totally different direction.
>
> We are making life worse for the zsh users by shipping our own
> version, aren't we?  If we didn't ship our own completion script for
> them, the user did not have to remove the one "which is considerably
> less complete/capable".
No. You are assuming the opinion of one user in Stack Overflow is a fact.

There's a reason people prefer to use Git's official completion, and there's a reason I wrote the wrapper.

The Zsh default completion is *incredibly* slow. Just as a point of comparison when I do `git checkout <tab>` on the Linux kernel git repository, it takes *three* seconds to complete. With the Git official completion it's instantaneous, just like in Bash.

This defeats the whole purpose of completion. If it takes less time for me to type the thing than it takes the completion to complete it, then the completion is useless. I explained this to the Zsh developers[1], and they didn't care.

They prioritize completeness over usability.
I even wrote a blog post about the issue:
https://felipec.wordpress.com/2013/07/31/how-i-fixed-git-zsh-completion/
> Perhaps we are misleading users with our
> version that has an implicit "came from those who know Git the best
> in the world" label that gives it more authenticity than it
> deserves.
And perhaps not.
> A good zsh autocompletion would need to be written and
> reviewed by those who know zsh completion well.
No. Those people don't care if their completion is unusable.

Zsh users want a completion that is usable, and achieves the purpose of a completion; to make the user more productive. Not a completion Zsh developers feel proud about.

> They also need to
> know Git somewhat, but the expertise on the former would be a lot
> more important, I would think.

I disagree. To make the Git completion fast, efficient, and consistent to how Git is supposed to be used, it's much more important to know Git.

For example, if you do `git <tab>` in Git's Zsh completion, you get only porcelain commands, if you do the same in Zsh's default completion, you get "check-attr" in the list, which I doubt any Git developer would consider something the user should see by default.

You can do `git check-<tab>` and the Git's Zsh completion I wrote will still complete it, even though it's not visible initially.

So in that sense *my* code is superior; 1) It shows only the common commands by default, 2) all commands can be completed anyway, and 3) can be configured to show aliases too, and the order can be configured too.

Why didn't the Zsh default completion do this? I don't know.
Show 9 quoted lines
> But as you said in
> <CAMP44s3wqxTmgQpMgk2cM33EvtwrvvXYv4_90GKGmHb8yJHAKg@mail.gmail.com>
>
>     The answer is obvious: the set of zsh users and the set of git
>     developers don't overlap.
>
> this community is not equipped to give good reviews and improvement
> suggestions on zsh matters to your patches.  And I do not have a
> feeling that the situation would change soon.
Neither does any other community.
But in this community at least some people try.
Show 7 quoted lines
> Do your recent 29-patch improvements not just fill the "gap" but
> surpass the one that comes by default with zsh?  I have this nagging
> feeling that the effort to make the autocompletion better for Git
> users who use zsh may be better made by you ("git blame" tells me that
> you seem to be the only one who's invested heavily in the script,
> unfortunately) joining forces with those who develop and maintain the
> autocompletion that comes by default with zsh.
This is not possible, as the Zsh maintainers don't care about usability.

Plus, the whole point of my wrapper is to leverage the Bash completion, which is actively maintained. The Zsh developers would *never* agree to use the Bash completion in any capacity.

The current situation is far from ideal, but I don't see any obvious way to improve it.

[1] https://www.zsh.org/mla/workers/2011/msg00506.html
-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 42 of 58 in “completion: a bunch of updates”
  1. 00/14 completion: a bunch of updatesFelipe Contreras, Jun 21, 2019
  2. 01/14 completion: zsh: fix __gitcomp_direct()Felipe Contreras, Jun 21, 2019
  3. Felipe ContrerasJun 22, 2019
  4. 02/14 completion: zsh: fix for directories with spacesFelipe Contreras, Jun 21, 2019
  5. 03/14 completion: remove zsh hackFelipe Contreras, Jun 21, 2019
  6. 04/14 completion: zsh: improve main function selectionFelipe Contreras, Jun 21, 2019
  7. 05/14 completion: prompt: fix color for ZshFelipe Contreras, Jun 21, 2019
  8. 08/14 completion: bash: remove old compat wrappersFelipe Contreras, Jun 21, 2019
  9. 07/14 completion: zsh: update installation instructionsFelipe Contreras, Jun 21, 2019
  10. 06/14 completion: bash: cleanup cygwin checkFelipe Contreras, Jun 21, 2019
  11. 09/14 completion: bash: remove zsh wrapperFelipe Contreras, Jun 21, 2019
  12. 11/14 test: completion: tests for __gitcomp regressionFelipe Contreras, Jun 21, 2019
  13. Junio C HamanoJul 3, 2019
  14. SZEDER GáborJul 3, 2019
  15. 10/14 completion: zsh: trivial cleanupsFelipe Contreras, Jun 21, 2019
  16. 12/14 test: completion: use global configFelipe Contreras, Jun 21, 2019
  17. Junio C HamanoJul 3, 2019
  18. 13/14 completion: add default optionsFelipe Contreras, Jun 21, 2019
  19. Duy NguyenJun 22, 2019
  20. Felipe ContrerasJun 22, 2019
  21. Junio C HamanoJun 24, 2019
  22. Felipe ContrerasJun 25, 2019
  23. Duy NguyenJun 25, 2019
  24. 14/14 completion: add default merge strategiesFelipe Contreras, Jun 21, 2019
  25. Junio C HamanoJun 24, 2019
  26. Felipe ContrerasJun 25, 2019
  27. Junio C HamanoJun 25, 2019
  28. SZEDER GáborJul 3, 2019
  29. Junio C HamanoJul 3, 2019
  30. SZEDER GáborJul 3, 2019
  31. Felipe ContrerasOct 25, 2020
  32. Felipe ContrerasOct 25, 2020
  33. Junio C HamanoOct 27, 2020
  34. Felipe ContrerasOct 27, 2020
  35. Junio C HamanoOct 27, 2020
  36. Felipe ContrerasOct 28, 2020
  37. Stefan HallerOct 28, 2020
  38. Felipe ContrerasOct 28, 2020
  39. Stefan HallerOct 28, 2020
  40. Junio C HamanoOct 29, 2020
  41. Junio C HamanoOct 29, 2020
  42. Felipe ContrerasNov 2, 2020
  43. Junio C HamanoNov 3, 2020
  44. Felipe ContrerasNov 4, 2020
  45. Junio C HamanoNov 4, 2020
  46. Felipe ContrerasNov 5, 2020
  47. Junio C HamanoNov 5, 2020
  48. Stefan HallerOct 30, 2020
  49. Junio C HamanoOct 30, 2020
  50. Felipe ContrerasNov 2, 2020
  51. Aaron SchrabNov 2, 2020
  52. Junio C HamanoNov 3, 2020
  53. Felipe ContrerasNov 3, 2020
  54. Felipe ContrerasNov 3, 2020
  55. Stefan HallerNov 3, 2020
  56. Junio C HamanoNov 3, 2020
  57. Stefan HallerNov 3, 2020
  58. Felipe ContrerasNov 2, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.