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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html