On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
<felipe.contre...@gmail.com> wrote:
> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen <pclo...@gmail.com> wrote:
>> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
>> <felipe.contre...@gmail.com> wrote:
>>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen <pclo...@gmail.com> wrote:
>>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>>>> <johannes.schinde...@gmx.de> wrote:
>>>>> Hi Greg,
>>>>> On Thu, 6 Jun 2013, Greg Troxel wrote:
>>>>>> As one of the people who helps maintain git packages in pkgsrc, my
>>>>>> initial reaction is negative to adding a ruby dependency.
>>>>> My initial reaction, too. It was hard enough to get Perl included with Git
>>>>> for Windows (because of that pesky Subversion dependency).
>>>>> As you can see from the commit history, I was the primary force behind
>>>>> trying to get everything "core" in Git away from requiring scripting
>>>>> languages (I think it is an awesome thing to provide APIs for as many
>>>>> languages as possible, but a not-so-cool thing to use more than one
>>>>> language in the core code). It does not seem that anybody picked up that
>>>>> task when I left, though.
>>>> Nobody seems to mention it yet. There's another reason behind the C
>>>> rewrite effort: fork is costly on Windows. The C rewrite allows us to
>>>> run with one process (most of the time). This applies for shell, perl
>>>> and even ruby scripts because libgit.a is never meant to be used
>>>> outside git.c context (unlike libgit2). In this regard, ruby is just
>>>> as bad as currently supported non-C languages.
>>> Are you sure?
>> I'm not saying you can't. I'm saying it's not meant to be used that
>> way. Which means there may be problems lurking around.
> Code is code. If something is not meant to be used in certain way, you fix it.

Code is code. Bugs can be hard and easy. Hard bugs take a lot of time
and may not be worth it after all.

>> You can write a ruby extension to access libgit.a, sure,
> I'm not using libgit.a, I'm using the builtin commands. This is
> exactly the same code you run when you type 'git foo'.
>> but how many people on this
>> list understand git design and limits _and_ ruby's good enough to spot
>> the bugs?
> Now you are changing the subject. Does that mean that you accept that
> 'fork' wouldn't be a problem when writing Ruby scripts?

There are a lot of static variables in builtin/ (and outside too),
which make it non-entrant, or at least not safe. fork provides a
process space isolation, some depend on that. And there are die()
everywhere. Good luck controlling them.

> As for the people that know Git and Ruby; they can learn. Didn't you
> just said that you didn't see any problem with the community learning
> a new language?

I said nothing about the community being ready _now_, did I? When you
have the support for Ruby in Git, sure go ahead.

>> If a bug is found and requires major restructuring in
>> libgit.a, how are you sure it's worth the effort and does not
>> destablize the rest of git?
> There is no need to destabilize anything. I just showed you 100 lines
> of code that are able to run git commands without forks, and without
> changing anything in libgit.a.

And how do you deal with, for example die(), or thread safety?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to