Zsh Mailing List Archive
Messages sorted by:
Re: git-completion 1.2 released
On Mon, Nov 23, 2020 at 9:44 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Felipe Contreras wrote on Mon, Nov 23, 2020 at 01:49:16 -0600:
> I suspect that TODO comment should simply be deleted for vagueness,
> especially given its age.
I suspect so too. It seems Nikolai Weibull added that comment for some
reason in 2011 but he hasn't been active for a lot of time and nobody
> > 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.
Well, I do fix bugs before they are reported, because I use git all
the time, and I use git completion all the time, and I also developed
a testing framework for the completion so users don't have to be
bitten by bugs in order to find them.
> > 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.
It depends what part of the tests you want to use. Many of the tests
were developed by me, so I own the copyright.
I pushed the branch to my repository:
32 tests fail, 38 pass.
Just run that script with Bash.
> > 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.
In many cases nobody reported the bugs to the Git mailing list either.
Git developers themselves find the areas of opportunity.
> 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).
But I'm talking more about the speed. This is the thing is very clear
Git developers care about, as they often perform tests on the Bash
completion itself, and optimize it, shaving milliseconds here and
I sent a patch to exemplify how this speed can be leveraged from Zsh's
official completion, for example using __git_complete_revlist, which
is extremely fast, compared to whatever the Zsh completion is doing.
Yes, it probably doesn't autocomplete exactly the same list, but it's
more than good enough.
These are the priorities I'm talking about; mainly the compromise in
completeness in order to get more usability (actually save the user's
time while completing commands).
Messages sorted by: