Re: Python extension commands in git - request for policy change

[Felipe Contreras <felipe.contreras@gmail.com>]

On Sun, Nov 25, 2012 at 6:32 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> Seems sensible, but I don't know what "rejection" would actually mean.
>
> Why is this mysterious?  We reject a patch when we don't choose to merge it.

Why would you reject it? If, according to you, it's very simple to fix
the portability, then presumably it would take you less time to fix
it, than to reject it (and everything that implies).

>> Too late.
>
> I'd be happy to help you out by auditing them for version dependencies.

Be my guest:
http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205

Some patches might be missing, so:
https://github.com/felipec/git/tree/fc/remote/hg

>> I don't see what this means in practical terms. People are going to
>> write code in whatever language they want to write code in. How
>> exactly are "we" going to "encourage" them not to do that is not
>> entirely clear to me.
>
> One way is by having clear guidelines for good practice that *include*
> Python, and tell people exactly what the requirements are.

The key word being guideline, which is different from a strict rule.

>> Subcommands are also probably more efficient in c. And lets remember
>> that most people use git through the *official* subcommands.
>
> See my remarks on the 80-20 rule elsewhere in the thread.  Execessive
> worship of "efficiency" is a great way to waste effort and pile up
> hidden costs in maintainance problems.

According to the results of the last survey, our users do care about
performance, so I don't think there's anything excessive about it. Are
there any hidden costs in maintenance problems? I don't think so.

The people that like to improve the performance of git, would keep
doing so, and the people that want to use fancy scripts to do fancy
stuff, will keep doing so. It just happens that the former have
actually managed to do it, and go all the way into the mainline.

It would be great if we had a finished libgit2 with all the essential
stuff, and good bindings for python (and other languages), and it
would be great if python really was this touted language, that is easy
to read, and would make things more maintainable. Unfortunately,
that's not the case.

I could write an endless list of what things in the python language
don't make any sense, and how in ruby, for example, they do.
Fortunately, I don't have to.

Git does have problems, but they have nothing to do with maintenance,
or C; they have to do with the user interface, and the documentation
(again, according to our users (and me)). So, I don't see why worry
about moving code from C to python when barely any code in git is
python, specially if it doesn't fix any real issue.

Cheers.

-- 
Felipe Contreras