On Sun, Sep 22, 2013 at 2:31 AM, Fredrik Gustafsson <iv...@iveqy.com> wrote:
> On Sun, Sep 22, 2013 at 12:36:51AM -0500, Felipe Contreras wrote:
>> > I think it's a bad idea to introduce an entirely new runtime, especially
>> > one known to occasionally blow up on less-common architectures, without
>> > some advance notice.
>> This is just FUD. What do you mean blow up on less-common architectures? Do
>> have actual evidence or can we just dismiss that as a baseless argument?
>> > For example, at work I would not be able to deploy a git using Ruby
>> > immediately because Git is an RPM and Ruby is compiled from source, if it
>> > is
>> > even present at all.
>> Again, what do you mean? In all the distributions I've seen, vim is compiled
>> with Ruby support by default, so unless you think vim is an essoteric
>> libruby is almost definetly packaged and available.
> It would actually be usefull to know stats on where git is runned. In my
> world of embedded computing, ruby support definitely isn't a standard,
> nor is glibc.
I come from the embedded world as well, and I've never seen Git used there.
I'd say Windows support is much more important than embedded, and we
are not supporting that properly.
>> > Also, the only Python script that is shipped with Git is git-p4, which
>> > is essentially optional, since most git users probably do not use
>> > Perforce. Otherwise, all the scripts in git are shell or Perl.
>> Neither perl, nor shell, nor python scripts solve the forking problem. My
>> proposal does.
> It does,
No, it does not. All the **current** perl/shell/python scripts use
'git foo' commands to achieve everything.
> and so does Lua,
There is no lua in Git.
> which can be bundled with git and used in the
> configuration files as well and is pure ansi C. However bundling
> something has it bad sides too. At least this will solve the dependency
> problem. So let the language war begin =).
Talk is cheap, show me the code.
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