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

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

[Ramkumar Ramachandra]

Hi,

I realize that we maintain a bash completion script, and a thin
wrapper around it for ZSH.  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?

Thanks.

[1]: https://github.com/zsh-users/zsh/blob/master/Completion/Unix/Command/_git

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

[Jonathan Nieder]

Hi,

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.

Kind regards,
Jonathan

http://thread.gmane.org/gmane.comp.version-control.git/210022/focus=210024

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

[Jonathan Nieder]

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.

Thanks for your interest,
Jonathan

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

[Felipe Contreras]

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.

If they wanted my contributions, that would be awesome, but that
doesn't appear to be the case. And I'm kind of relieved, because zsh's
completion is monstrous code, and the zsh development practices are
not good (e.g. all my logically independent patches get squashed into
one commit).

Cheers.

[1] https://github.com/robbyrussell/oh-my-zsh

-- 
Felipe Contreras

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

[Felipe Contreras]

On Sat, Apr 20, 2013 at 5:39 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> 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

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

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> 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 see.  Yes, I was looking for a reason like this.

True.  I've noticed that my shell just hangs when I attempt to
tab-complete too early/ something wrong, and this would be nice to
fix.  Does it have to be a hard trade-off between correctness and
speed?  Is it not possible to reach a fair compromise?

Now, I don't know anything about zsh's git completer versus the
gitfast completer.  From a glance, it looks like zsh's git completer
is much larger and stuffed with features that the gitfast completer
doesn't have.  Although I agree that speed isn't the only parameter,
can you shed some light on how these two compare on other parameters?

Or you could help me figure all this out myself.  How do I
profile/debug shell code?  I'm feeling a little lost without gdb and
valgrind.

> And I'm not the only one, when I contributed this stuff to
> oh-my-zsh[1] I got a very positive response.

Found it: https://github.com/robbyrussell/oh-my-zsh/commit/5a11228

> If they wanted my contributions, that would be awesome, but that
> doesn't appear to be the case. And I'm kind of relieved, because zsh's
> completion is monstrous code, and the zsh development practices are
> not good (e.g. all my logically independent patches get squashed into
> one commit).

I see.  I've just started poking them with patches.  I'll see what
happens for myself.

Cheers.

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

[Felipe Contreras]

On Sat, Apr 20, 2013 at 11:36 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> 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 see.  Yes, I was looking for a reason like this.
>
> True.  I've noticed that my shell just hangs when I attempt to
> tab-complete too early/ something wrong, and this would be nice to
> fix.  Does it have to be a hard trade-off between correctness and
> speed?  Is it not possible to reach a fair compromise?

It doesn't matter, the zsh folks don't want *any* compromise:
http://article.gmane.org/gmane.comp.shells.zsh.devel/22475

> Now, I don't know anything about zsh's git completer versus the
> gitfast completer.  From a glance, it looks like zsh's git completer
> is much larger and stuffed with features that the gitfast completer
> doesn't have.  Although I agree that speed isn't the only parameter,
> can you shed some light on how these two compare on other parameters?

First of all, 'gitfast' is just the name I gave to the oh-my-zsh
plugin that uses git.git's completion stuff. The zsh support in git's
bash completion has been working for years, I just copied the stuff to
oh-my-zsh so those guys can use it easily. I also added my thin zsh
wrapper, because of issues with zsh's bash completion emulation, but
that's not specific to oh-my-zsh in any way.

Secondly, I don't see what "features" zsh's git completer might have
that we don't. Yes, some specific argument behaviors are nice, like
adding a '=' after --git-dir, and then complete only directories, and
completion descriptions, along with tag groupings, but all those
things are cosmetic, and they could be added relatively easy to my
thin wrapper (which wouldn't be so thin after all). It's mostly grunt
work, not something that requires a great mind.

Functionally I don't see any value.

For example, a difference is that when you do 'git show v<tab>',
git.git bash's completion will show refs, and only if there aren't any
that could match, show files, any files. zsh's version will show both
files and refs at the same time, and if you have grouping enabled they
would show that way, in the git.git repo I see them grouped in commit
tag, tag, 'cached file' (although showing tags twice is probably a
bug), and only the files present in the repository.

Another one is that when you do 'git add <tab>', you see the results
grouped for example in 'modified file', 'untracked file', whereas in
bash they can't be grouped.

Are these minor features worth all this slowness and complicated code?
I don't think so.

Also, the grouping requires a configuration like:
zstyle ':completion:*:descriptions' format '%B%d%b'
zstyle ':completion:*' group-name ''

And I bet most people don't have such configuration. So all this
complicated code achieves nothing for the majority of users.

The reason why I prefer git.git's bash completion is that it has taken
years to develop, and using good development practices, borrowed from
the mainline git process. Many more people use them, have debugged
them through the years, and optimized them. It's relatively small
(compared to zsh's version), much more readable, and it even has tests
(which I helped to start), and it's much less buggy. It's basically
rock solid.

Just now I was reading about a bug in zsh-workers when you do 'git
show v3<tab>' in the Linux kernel git tree, and you can count the
seconds before it completes. This is the sort of thing that just
doesn't happen with git's bash completion.

> Or you could help me figure all this out myself.  How do I
> profile/debug shell code?  I'm feeling a little lost without gdb and
> valgrind.

For git.git's bash completion I just run a script that exercises the
function I'm interested in with perf. Fortunately nothing there is
really slow, so I don't have to track offenders (usually).

Unfortunately zsh's completion stuff can't be scripted, or at least I
haven't managed to find a way to either profile or write tests for any
of that code.

>> If they wanted my contributions, that would be awesome, but that
>> doesn't appear to be the case. And I'm kind of relieved, because zsh's
>> completion is monstrous code, and the zsh development practices are
>> not good (e.g. all my logically independent patches get squashed into
>> one commit).
>
> I see.  I've just started poking them with patches.  I'll see what
> happens for myself.

Yeah, I did contribute patches myself too. As long as they are
superficial, like adding a missing argument or so, they are fine. But
don't try messing with their precious "completeness".

Cheers.

-- 
Felipe Contreras

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

[Ramkumar Ramachandra]

Felipe Contreras wrote:
> First of all, 'gitfast' is just the name I gave to the oh-my-zsh
> plugin that uses git.git's completion stuff. The zsh support in git's
> bash completion has been working for years, I just copied the stuff to
> oh-my-zsh so those guys can use it easily.

Yeah, I know.  I just used the name.

> Secondly, I don't see what "features" zsh's git completer might have
> that we don't. Yes, some specific argument behaviors are nice, like
> adding a '=' after --git-dir, and then complete only directories, and
> completion descriptions, along with tag groupings, but all those
> things are cosmetic, and they could be added relatively easy to my
> thin wrapper (which wouldn't be so thin after all). It's mostly grunt
> work, not something that requires a great mind.
>
> Functionally I don't see any value.

> Are these minor features worth all this slowness and complicated code?
> I don't think so.

Moved to using git.git's completer, and I see that you're absolutely
right about the "minor features" missing part.  I just assumed that
zsh's completer must be more complete because it's so much larger than
git.git's bash/zsh completer.  Working backwards from zsh's completer
would've been a nightmare.

> The reason why I prefer git.git's bash completion is that it has taken
> years to develop, and using good development practices, borrowed from
> the mainline git process. Many more people use them, have debugged
> them through the years, and optimized them. It's relatively small
> (compared to zsh's version), much more readable, and it even has tests
> (which I helped to start), and it's much less buggy. It's basically
> rock solid.

Great!  I'll stop working on zsh's completer immediately, and try to
redirect my attention on improving git.git's completer instead.

Thanks for the information.