When can we make a compromise in Git completion?

When can we make a compromise in Git completion?

[Felipe Contreras]

On Fri, May 6, 2011 at 12:12 AM, Nikolai Weibull <now@bitwi.se> wrote:
> On Thu, May 5, 2011 at 22:14, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Thu, May 5, 2011 at 10:38 PM, Bart Schaefer
>> <schaefer@brasslantern.com> 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

Re: When can we make a compromise in Git completion?

[Bart Schaefer]

On May 6,  1:07am, Felipe Contreras wrote:
} Subject: When can we make a compromise in Git completion?
}
} 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'.

With the patch, however, it's possible for you to plug in your own
different plumbing using zstyle.

zstyle ':completion::complete:git:*:files' command ...

where you put your alternate plumbing in where I have "...".

Then when you have something that works as fast/accurately as you care
about, you can let us know.

If that's not good enough you can rewrite __git_files (or any of the
other functions in the _git file) from scratch; there's a reason that
the source file tests (( $+functions[__git_files] )) || ... before
each function is defined:  so that you can override them simply by
defining your own flavor before _git is autoloaded.

} 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?

Roughly at the time you stop taking such an antagonistic stance about
it, I suspect.  Really, you're not doing your efforts any favors by
framing the discussion the way you do.

Whether Nikolai personally accepts your suggestions for inclusion in
his contributed code is actually something of a side issue.  The real
question is whether this is important enough to you to make it work for
yourself.

Re: When can we make a compromise in Git completion?

[Felipe Contreras]

On Fri, May 6, 2011 at 1:37 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 6,  1:07am, Felipe Contreras wrote:
> } Subject: When can we make a compromise in Git completion?
> }
> } 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'.
>
> With the patch, however, it's possible for you to plug in your own
> different plumbing using zstyle.
>
> zstyle ':completion::complete:git:*:files' command ...
>
> where you put your alternate plumbing in where I have "...".

I don't think it would be that easy.

> Then when you have something that works as fast/accurately as you care
> about, you can let us know.
>
> If that's not good enough you can rewrite __git_files (or any of the
> other functions in the _git file) from scratch; there's a reason that
> the source file tests (( $+functions[__git_files] )) || ... before
> each function is defined:  so that you can override them simply by
> defining your own flavor before _git is autoloaded.

I believe every __git_.*_files has to be changed. So again, not that easy.

Why would I even try if the result of this work is going to the trash?
First you tell me you would consider it for merging, then I will try
it, no point otherwise.

> } 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?
>
> Roughly at the time you stop taking such an antagonistic stance about
> it, I suspect.  Really, you're not doing your efforts any favors by
> framing the discussion the way you do.

This has nothing to do with feelings, it's a technical issue. Either
you are willing to make a compromise or not.

You pointed to other mailing list customs earlier, well, on the linux
kernel mailing list politeness is not a requisite, code is: "talk is
cheap, show me the code". But what I hear you saying is; "we don't
want that code".

It is a simple question, why can't you give a straight answer?

-- 
Felipe Contreras

Re: When can we make a compromise in Git completion?

[Clint Adams]

On Fri, May 06, 2011 at 02:01:20AM +0300, Felipe Contreras wrote:
> Why would I even try if the result of this work is going to the trash?
> First you tell me you would consider it for merging, then I will try
> it, no point otherwise.

I have dealt with projects where getting patches accepted is
difficult and aggravating, where patches get rejected for
ridiculous reasons like punctuation in commit logs, where
submitters give up after a few attempts and then the fixes
never make it into mainline.

This project is not one of those.

Provide a superior method and I'll be surprised if it gets
rejected because someone is being pigheaded or territorial.

Re: When can we make a compromise in Git completion?

[Bart Schaefer]

On May 6,  2:01am, Felipe Contreras wrote:
} Subject: Re: When can we make a compromise in Git completion?
}
} On Fri, May 6, 2011 at 1:37 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > zstyle ':completion::complete:git:*:files' command ...
} 
} I don't think it would be that easy.
} 
} I believe every __git_.*_files has to be changed. So again, not that easy.

Then you haven't actually looked.  Nearly all __git*files are wrappers
around __git_files, and __git_files is the only [*] place where ls-files
is used, and that zstyle will swap out that call for whatever you say
should be used instead; or you can replace __git_files and interpret
directly the arguments that it's given.

Maybe __git_tree_files also needs to avoid ls-tree, but in that case
there's also

zstyle ':completion::complete:git:*:tree-files' command ...

[*] This modulo the fact that Nikolai's patch missed a couple of cases
that still want to refer to __git_files_relative, which we haven't yet
come up with a fix for.

} This has nothing to do with feelings, it's a technical issue. Either
} you are willing to make a compromise or not.
} 
} You pointed to other mailing list customs earlier, well, on the linux
} kernel mailing list politeness is not a requisite,

Politeness isn't necessarily a requisite here, either, but the content
of remarks should at least move the discussion forward.  If you're not
actively helping the process, being impolite isn't going to convince
someone else to do it for you.

} code is: "talk is cheap, show me the code".

... and have you ...?

} But what I hear you saying is; "we don't want that code".
} 
} It is a simple question, why can't you give a straight answer?

Because whether we want the code depends on what we see once you show
it to us.  Especially within in the completion system, functions are
provided by those who are interested enough to want to use them.  Code
can be offered as contributions and may or may not be accepted.  MOST
of the time, it is accepted, but if this isn't an interesting or useful
(to *you*) project even if we turn you down, there's not much more I
can say to you.

I personally have reached the end of giving advice on how to proceed,
at least until there's something more specific to dicuss.

--