About git.git zsh's completion

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

Hi,

Reading the archives I noticed my name mentioned a few times, and I
would like to make some corrections to what was said, but first, I
would like to clarify the reason for git.git zsh's completion.

First of all, there seems to be a misconception; there is not only
bash completion, but there is also *zsh* completion in git.git. In
upstream, zsh' completion is nothing more than a thing wrapper around
the bash completion, which I wrote due to bugs in zsh's bashcompinit,
but I already have patches that improve on top of that, add
zsh-specific options[1].

This is the officially recommended way of completion git commands in
zsh, from the git project, a lot of git users are happy with it, and
recently oh-my-zsh has adopted it, with very positive feedback, and as
many users have stated; it's way faster than zsh's _git completion.

So don't make it look as if I'm oppose to zsh-specific completions.
I'm not. I'm actually writing them.

My objectives are to have fast zsh completion, as fast as bash ones,
if possible having description, and other niceties from zsh, but
without compromising speed, nor correctness. And by correctness I
don't mean the same thing as zsh developers do, I mean not having the
typical issues that have plagued git's bash->zsh completion for quite
some time (e.g. 'git show HEAD:<tab>' not completing anything).

Now, I'll address the slander:

> The thing with previous encounters (I'm recollecting from memory here,
> and I hope I'm not too inaccurate) is that Felipe pretty much
> demanded, not asked - demanded, that all features that slowed the
> completion down should be removed, not be made optional - removed,
> even though the original author (Nikolai) put a lot of time into
> realising those features.

This is totally false, I never demanded anything, I argued. Show me
the exact mail in which I demanded anything. There isn't one.

And for the record, my argument was that the purpose of completion is
to be able to type commands faster, and if the completion takes longer
than the command, and in this case, several orders of magnitude slower
than the command, the completion is failing it's purpose.

I asked if Nikolai was willing to compromise, and the answer was a rotund NO.

There's no point in discussing with people that don't have an open
mind and are not willing to listen to reason.

> He was also completely against putting time into finding the root
> cause of the problems, so that maybe the additional features could be
> kept and sped up - even though people told him, they liked those
> features and they didn't see the impact (because they only get really
> annoyingly relevant on large repositories like the linux kernel, which
> not everybody works on - there is also not a lot of negative feedback
> on these mailing lists or the freenode IRC channel about the _git
> completion).

People like those features? Who? Zsh developers? That's a tiny
minority of the user-base, making generalizations from this user-base
is bound to be wrong. There's far more people using bash's git
completion, and they haven't complained about these features. And in
the few months oh-my-zsh folks have had the official git completion,
all I've heard is positive feedback about the speed, and *zero*
negative feedback about missing features.

Also, you don't have to brainwash Ramkumar, he already knows zsh's _git is slow.

> This whole _git business is rather off-putting and I'd like to avoid
> putting any more time and energy into any "politics" that are involved
> on either side. This is no fun. I don't want to get steamed up about
> things like this.

Me too. A first good start would be to come up with a middle ground
between features and speed, and in fact, it wouldn't be so in the
middle, it would be pretty much where zsh's _git is, except without
one or two features, that could be easily added back by me, in time.

But you won't do that. Why? Because of *political* reasons.

> Maybe Nikolai would be willing to try and tackle the more fundamental
> problems.

Yeah, right. It has been _years_ since I reported these problems, and
they haven't been fixed. If Ramkumar reports them, and you fix them
right away, what does that tell about you? That you play favoritism
with your user-base, and that you don't care about ideas, but people;
ad hominem.

> Well, the bash and zsh completion mechanisms are pretty different.
> There are some features that zsh provides, that you just can't map to
> bash.

We have git-completion.zsh, we are not stuck with bash.

> Felipe seems to apply his bullying tactics to any project that doesn’t
> do as he wishes, see, for example,

You must have a pretty wicked definition of bullying. I was the one
being bullied, I was making arguments, and suddenly I was silenced,
the ticket was marked as private, and I simply shouted what was
happening, nothing more. After that, they retracted their decision,
and the conversation continued amicably, but it's not clear if it was
done purely for marketing reasons, as there hasn't been any further
reply.

Not that this this has *ANYTHING* to do with zsh. Stop trying to argue
by ad hominem.

> Git is still moving fairly fast, and the _git completion is basically
> written and maintained by one guy. One.

Exactly, and that's a bad thing. And it won't improve if you keep your
attitude of *no compromises*, ever.

> Ah, that’s the difference, then.  I/we just threw something together
> over the weekend.

/You/, as in a single person, might have worked for years, but not the
whole project, and certainly not with the same standards as the git
project. You don't split your commits into logical patches, you don't
review every single change through the mailing list, you don't have
tests specific to the git completion, you don't have multiple persons
updating the arguments, the tests, and improving the performance of
the completion. But more importantly, you simply don't have as many
users.

I've done a ton of work for git's bash and zsh completion, to the
point that it works much better now on both, if you had accepted my
help, there might be more than one person working the script by now,
but you didn't. You decided "completeness", a totally irrelevant
feature for most users, was more important than anything else, well,
you now have completion that is "complete", but rotting.

Even more, you continually argued that the features I wanted could be
added with extensions, well, the features *you* wanted
("completeness") could be added with extensions too. Ultimately what
is important is what the majority of users need, and that's not
completeness.

If you had accepted the compromise, by now I quite likely would have
fixed the speed issues, and would have added all the "completeness"
that you love so much. But now, you had to be unreasonable and
uncompromising, well, I hope you are happy with your decision.

I still hope that you realize that compromises are OK sometimes, and
decide to work together, but I'm not holding my breath. I'm fairly
certain that as time goes by, git's zsh completion will start eating
the zsh _git user-base. Because the features you think are so
important, aren't.

Cheers.

[1] https://github.com/felipec/git/blob/fc/zsh/ng/contrib/completion/git-completion.zsh
[2] https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/gitfast

-- 
Felipe Contreras