Re: [PATCH 2/3] Completion/Unix/Command/_git: fix shortlog completer

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Ramkumar Ramachandra wrote:
[...]
> Now, I'm a shell-scripting beginner and do not have the expertise to
> fully evaluate zsh's completer versus git.git's completer.  From my
> untrained eyes, zsh's completer looks more complete and comprehensive
> but git.git's completer looks terse and less intimidating.  There is
> definitely a noticeable difference in speed: git.git's completer is
> much faster, and there's no doubt about that.

It definitely is.  It does a bit less though.

It's also more up to date. And the reason for that is simple. Git is
still moving fairly fast, and the _git completion is basically written
and maintained by one guy. One. A few people tried to chip in every once
in a while (myself included), but since nobody of those people really
follows git's development too closely that's a battle you cannot win.

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. 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). Long story short, Felipe's rather hostile tone got him a
pretty short-spoken final reply from Nikolai, which he now shows off to
anyone who does or doesn't ask.


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.


> I want to work on the completer without fundamentally difficult
> problems (because I can't fix those fundamentally difficult problems).

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

> Speed seems to be a big pain point in zsh's completer, and that seems
> to be a very difficult problem to solve (I saw a few list emails about
> it).  However, it looks like we can gradually make git.git's completer
> more comprehensive.

This thing with speed is this: Yes, _git is slower than the bash
completion. But - at least when I last looked - _git will provide much
more useful suggestions depending on the context of the cursor position.
And I - personally - am happy to wait for, say, a second if that means I
can save several seconds selecting the right choice. However, some
completions are too slow on really large repositories. That would be a
useful area to improve - maybe make the slow smartness optional? I don't
know.

> That's all I really have.  Can you help me out, and tell me more?

The one thing, that _git lacks the most is able bodies. People, who are
willing to update the different sub-command handlers to the current git
development. Command --options, git-config options, new sub-commands.
You name it. Nikolai can't do it all on his own, unless _git is his only
project in life, which it is not.

> I would really like for us all to work on one completer.

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.
That makes one source to rule them all rather hard. And besides, I don't
think Felipe would let any feature suggestion in that adds smartness to
bash's completer, that would impact any of his use-cases.

That being said, if git would provide a way of saying "The git-am
command supports the following flags [...] and the --directory option
expects the value type of value: ...", then bash and zsh could both
_generate_ completers based on that. Might be neat, but sounds like a
bit of work. ;)


Okay then. This is far more than I thought I'd ever write on the subject
again, but since you asked nicely, you deserved a reasonable answer.

Thanks for your patches and good luck with whichever completion you
decide to work on!

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925