Re: git-completion 1.2 released

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

Felipe Contreras wrote on Thu, 19 Nov 2020 16:05 +00:00:
> Git-completion is a friendly fork of the official Git completion and
> prompt scripts for Zsh and Bash.
> 
> The main goal is to provide a more up-to-date completion for Zsh (I'm
> the developer), which is basically just a wrapper around the Bash
> completion.

I was going to invite you to send patches to zsh's own _git, but then I
noticed that in README.asciidoc you claim that you've sent patches to
zsh's completion and "many" of them have been "ignored":

> > Most Git developers use the Bash shell, for which the completion scripts work
> > rather well, however, Zsh is typically neglected. I've sent many patches to fix
> > the issues, many have been merged, but many have been ignored, thus the need for
> > a canonical location of a good, working Zsh completion.

I went back through the archives (and by this I mean the _complete_
archives, all the way back to 1995) and looked for git-related patches
and threads from you (using «~(~f Contreras ~s 'git|patch')» in Mutt, if
anyone wonders).  Here's what I found:

In April 2011 you sent 29208, which was accepted; 29041, which was
accepted; and 29055, which began a long thread that doesn't contain any
unified diffs.  I didn't read the thread in full since, according to the
subsequent thread starting in 29158, the 29055 thread ended up in
a disagreement not unlike the one you and Roman had just this week.

I also saw your 31343 and 31415, but they don't contain patches.

Which is to say, I have not found a _single_ patch from you that has
been "ignored", and for that matter, I haven't found a single patch from
you that has "not been merged", either; and the last _git-related
disagreement between you and the zsh developers is almost a decade ago.

Which is to say, I have failed to convince myself that the statement in your
README.asciidoc is accurate.

The invitation stands.

> Compared to Git upstream, you get many benefits for Zsh, for example:
> no extra unnecessary spaces, correct auto suffix removal, colors
> without PROMPT_COMMAND, custom aliases, fixed --no-options, and many
> more.

I suspect some of these have been fixed in zsh's _git since you last
looked and others are configurable.  (E.g., git-send-email(1), which you
mention below, completes not only files but also recent commits, and has
done so for a while.)

I also suspect that zsh's _git has features that yours lacks.

> If you use the official Zsh completion the main benefit is that it's
> blazingly fast. Simply doing "git log <tab>" on the Linux kernel (with
> 3k+ refs) takes several seconds on the official Zsh completion (about
> 3 seconds on my machine), with git-complete it's *instantaneous*.
> 

Are you comparing apples to apples or to oranges?  I.e., does it take
more time to produce the _same set_ of result, or to produce a
different set?

> There's other benefits too. Since the Bash completion is actively
> maintained by Git developers, everything works as they intend too.
> 
> For example "git send-email <tab>" correctly completes branches, as
> opposed to files in the Zsh official completion. Also, complex aliases
> such as '!f () { }; f' are correctly identified and completed
> out-of-the-box.
> 
> It's a sister project of the Oh My Zsh gitfast plugin [1], which I maintain too.
> 
> Since the last version a testing framework was added, and now all the
> completion tests of the Git project pass with the Zsh wrapper too [2].
> 
> For installation instructions, and more information, check the wiki
> [3], but basically.
> 
>  * make install
>  * fpath=(~/.local/share/git-completion/zsh $fpath)
> 
> Enjoy.
> 
> [1] https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gitfast
> [2] https://travis-ci.org/github/felipec/git-completion
> [3] https://github.com/felipec/git-completion/wiki/Zsh
> 
> -- 
> Felipe Contreras
> 
>