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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html