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

Re: [QUERY] Why do we have git-completion.zsh?

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Apr 21, 2013, 01:21 UTC
Message-ID
<CAMP44s3T7aoN_X5vvA3wb0pm1djXSvjy_DzTvG3TYKXS+ZbLYQ@mail.gmail.com>
In-Reply-To
<CAMP44s3yCW-pHVHc9WfL1BC7BKmnXxZ1WQyPRAMnx967=74_Kg@mail.gmail.com>

On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 49 quoted lines
> On Sat, Apr 20, 2013 at 1:53 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Jonathan Nieder wrote:
>>> Ramkumar Ramachandra wrote:
>>
>>>>                             However, I don't understand why we
>>>> maintain it, because there's a comprehensive first-class completer in
>>>> ZSH core [1] which I use all the time.  Shouldn't the completion folks
>>>> be contributing to this instead?
>>>
>>> Only if they want to.
>> [...]
>>> http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024
>>
>> Sorry, wrong link.  Here's a better one:
>>
>> http://www.zsh.org/mla/workers/2011/msg00497.html
>>
>> More fundamentally, your question seems to assume some kind of shared
>> plan regarding what people work on, rather than each person choosing
>> to work on what they consider valuable without having to justify it to
>> others.  I am very happy with Felipe's work on git's completion code
>> and don't think it does any harm to efforts elsewhere.
>
> To complement the reason; the zsh folks (or perhaps it's only one; who
> works on the git stuff), absolutely prioritize "correctness" over
> speed, that means if it takes ten seconds to list all the possible
> files to complete, grouped nicely, that's exactly what they'll do,
> instead of the way the bash completion does, which lists the most
> likely files, which takes milliseconds.
>
> I found zsh's completion unbearably slow, which is ironic; git is the
> fastest DSCM on Earth, and they blow the performance away by making
> the completion dead slow, to the point where the completion is several
> orders of magnitude slower than the actual command. To me, the whole
> point of the completion is to make the work faster, and if the
> completion takes longer than me typing it, what's the point of it?
>
> And I'm not the only one, when I contributed this stuff to
> oh-my-zsh[1] I got a very positive response.
>
> I couldn't convince them of this obvious fact, so I choose git's bash
> fast completion.
>
> I have patches to improve the zsh thin wrapper to give more
> information, zsh style, in a way that is superior to zsh's git
> completion, but I'm still not happy with them, I want the user to be
> able to configure the output so it's not totally bloated like in zsh,
> and I'm still working on it. In the mean time, I want my completion to
> be blazingly fast, and at least as good as git's bash completion.

Actually, it's mostly there now: https://github.com/felipec/git/blob/fc/zsh/ng/contrib/completion/git-completion.zsh

This greatly improves 'git <tab>' over the plain bash version, and it's even better than the official zsh version, because you can do something like:

  zstyle ':completion:*:*:git:*' tag-order 'common-commands porcelain-commands'

To show only the command groups you are interested on. With official zsh, you get the whole enchilada of all the commands git has. Hardly user-friendly.

Cheers.
-- 
Felipe Contreras
Previous: Felipe ContrerasNext: Ramkumar Ramachandra
Message 5 of 8 in “[QUERY] Why do we have git-completion.zsh?”
  1. Ramkumar RamachandraApr 20, 2013
  2. Jonathan NiederApr 20, 2013
  3. Jonathan NiederApr 20, 2013
  4. Felipe ContrerasApr 20, 2013
  5. Felipe ContrerasApr 21, 2013
  6. Ramkumar RamachandraApr 21, 2013
  7. Felipe ContrerasApr 21, 2013
  8. Ramkumar RamachandraApr 21, 2013

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.