Re: git-completion 1.2 released

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Felipe Contreras wrote on Mon, Nov 23, 2020 at 01:49:16 -0600:
> On Sun, Nov 22, 2020 at 10:34 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > Felipe Contreras wrote on Sat, Nov 21, 2020 at 18:53:56 -0600:
> 
> > > But the main use of "git send-email" is not to receive random files,
> > > it's to receive comittishes, and potentially some .patch files.
> >
> > So, just this?  Will anyone want to complete files that _don't_ have
> > a .patch extension?
> 
> Usually "git send-email" receives the patches generated by "git
> format-patch", so yeah, *.patch should be enough. But it probably
> wouldn't hurt to add *.diff files too, just in case.

Let's do that for 5.9, then.  Thanks.

> > > If I do "git send-email master..<tab>" nothing completes with Zsh's
> > > official completion. It does with mine.
> >
> > Thanks for the bug report.
> 
> You're welcome.
> 
> But that's just an example. Another example is that "git -C ~/dev/git
> show <tab>" doesn't work,

That looks straightforward to add, considering the --git-dir/--work-tree
support already in place.

> and the _git function has a TODO about -c since 2011.

That TODO is so vague that it may well have been fixed at some point in
the intervening decade.  For instance, it so happens that I did a bunch
of work on -c, but that work was in _git-config and I never saw that
TODO comment until now.

I suspect that TODO comment should simply be deleted for vagueness,
especially given its age.

> And there's a lot of others.
> 

If so, they haven't been reported.  We can't fix bugs unless they are
reported to us.

> I did some hacks to run Zsh's official Git completion against Git's
> testing framework, and at least half of them fail. I could tell you
> how to do that if you are interested.

Thanks for the offer.  We would be interested, if the results could be used
without licensing concerns.  zsh's _git is BSD-licensed.

> So in my view it's clear the priorities of the two completions are
> very different.

It's nothing as deliberate as that.  It's more likely just that nobody
ever reported the bug whilst someone able and inclined to fix it
happened to be listening.

Also, in the specific case of «git -C», the Git maintainers probably use
that option far more often than the average zsh user does (to run their
HEAD builds against test repositories).

Cheers,

Daniel
(Will read the other emails later; got to leave now.)