When can we make a compromise in Git completion?

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Fri, May 6, 2011 at 12:12 AM, Nikolai Weibull <now@xxxxxxxx> wrote:
> On Thu, May 5, 2011 at 22:14, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> On Thu, May 5, 2011 at 10:38 PM, Bart Schaefer
>> <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
>>> Nikolai put a lot of effort into the current version and as we're all
>>> volunteers here I can't fault him for not wanting to expend effort on
>>> gutting it.  In the same way that the bash variant is good enough for
>>> you, what he's contributed is presently working the way he prefers.  If
>>> no one else is available to produce an alternative, well, that happens
>>> sometimes with a volunteer work force.
>
>> That's not the case, I volunteered myself to do that, but what's the
>> point if he is going to reject the patches?
>
>> Again, I did volunteer, didn't you see the link on the mail you just replied?
>>> [1] http://article.gmane.org/gmane.comp.shells.zsh.devel/22480
>
> Please stop trying to rewrite history.  It’s not Git-like.  I can
> quote history too:
>
> http://article.gmane.org/gmane.comp.shells.zsh.devel/22488

I don't see anywhere there that you would be willing to accept a patch
that makes a compromise. Did I miss that part?

> I don’t know how much of the rest of the thread you didn’t read, but I
> did actually solve the problem:
>
> http://article.gmane.org/gmane.comp.shells.zsh.devel/22491

Actually I saw that mail by looking at the archives, but I didn't
notice the patch. I have tried the patch, it's still *dead slow* for
me. Again, I don't think this can be solved without writing new git
plumbing. You need to avoid 'git ls-files'.

So. At which point are you going to be willing to accept the fact that
it's not possible to fix the performance without making a compromise?
One week? One month? This issue seems to have been going on for
*years*.

-- 
Felipe Contreras