brian m. carlson wrote: > On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote: > > On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson > > <sand...@crustytoothpaste.net> wrote: > > > As Junio has also pointed out in the past, there are people who aren't > > > able to use Ruby in the same way that they are Perl and Python. If it's > > > announced now, Git 2.0 might be a good time to start accepting Ruby > > > scripts, as that will give people time to plan for its inclusion. > > > > Yes, and there are people who aren't able to use Perl/Python in the > > same way they use Ruby. That's why I tried to show why Ruby makes a > > perfect choice. > > I'm not arguing against Ruby. As I said, it's a nice language. I'm > just saying that Ruby is not as common as Perl and Python.
In my books Perl is only a tiny bit more common than Ruby. http://www.tiobe.com/content/paperinfo/tpci/index.html > 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. > 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. > So this would be adding a significant additional dependency to core git, one > which is likely not installed on many systems. Another claim without a shred of evidence. It's the other way around, it's likely already installed, and it would not be an additional dependency if the current scripts get phased out in favor Ruby ones, or even better, C code. > Of the systems in the Debian popularity contest, 41% have git installed and > 23% have ruby1.8 installed, with only 16% having the default ruby installed. Plus the 17% of ruby1.9.1, you get 41%, exactly the same as Git. But we don't need ruby, all we need is libruby, which is 47%. > > Now, if anybody has ideas into how the bindings could be more object > > oriented, I'm all ears, but unfortunately what I foresee is that > > nobody will consider this proposal seriously. > > My concern is that the Ruby code will end up not being idiomatic, and > people will view it as bizarre and unmaintainable. There is no such thing as idiomatic Ruby code. In Ruby there's no single best way to do something, there's many ways to do the same thing. > for_each_ref could end up being something like REPOSITORY.refs.each, > which would be more idiomatic. And how do you propose to achieve that if the C code doesn't support that? Do you have in mind the C code that would achieve that, or are you just saying? -- Felipe Contreras -- 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
