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 > you > 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 package, > 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. As for architecture speaking I think it's important that git works on ARM since that architecture increases on the server market. I've no idea if this is a problem with ruby or not. > > > 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, and so does Lua, 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 =). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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
