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

[Ramkumar Ramachandra <artagnon@xxxxxxxxx>]

Frank Terbeck wrote:
> 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.

Yeah, I saw the shortlog/ blame for each of them.  git.git's completer
has a _lot_ of contributors.  Tons of eyes looking at the code.

I follow git's development quite closely -- I'm quite active on the
mailing list.  Like I said before: I'm not taking sides, so there's no
"battle": it's a simple task of picking one completer, and merging the
other's strengths into it.

> 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.

Got it.  However, why are we talking about him?  We're not interested
in changing Felipe's behavior (even if we did have some magical way to
do that).  Let us focus on which completer to work on by looking at
the two completers.

> 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.

Why are you getting steamed up?  What politics are you talking about?
Someone on the internet has a rather strong opinion on zsh's
completer, and he tells it to whoever asks him.  That's it.

> 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.

The question is: which way to start work from?

I personally prefer git.git's completer, because snappiness is very
important to me.  I'm even a little annoyed with Magit, because of the
speed issue.

> 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.

Isn't it a matter of writing a larger zsh wrapper?  Yes,
git-completion.zsh is small.

Felipe is nobody.  He doesn't control the git project, the completer,
or anything else.  The git mailing list is filled with extremely
sensible rational people.

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

Thanks for the explanation.