On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson <iv...@iveqy.com> wrote: > On Sun, Sep 22, 2013 at 02:43:39AM -0500, Felipe Contreras wrote: >> > 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. > > Me neither, it doesn't mean that it isn't used though... I agree with > the lack of windows support from git.git.
Sure, it *might* be used, but I don't understand this fascination about worrying about hypothetical users, possibly non-existent, when we have real users to worry about, and in big numbers. > However since Microsoft > working with libgit2 on a Visual Studio plugin this it might be that the > need for windows support decreases. I'll believe it when I see it. And then, when the users like it and don't report brokenness. Personally, I don't have much faith the in the libgit2 project, and it's ability to keep up with git.git. >> >> > 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. > > As I said, "It does" meaning "Your solution solves the forking problem". Oh. >> > and so does Lua, >> >> There is no lua in Git. > > There's no ruby in git either as far as I know... (and no, I don't think > contrib/ counts). There is when you apply this patch. >> > 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. > > See this thread by Jeff King: > http://thread.gmane.org/gmane.comp.version-control.git/206335/focus=206337 That is very very far from what I'm doing. > And see my humble test of what the speedup would be for git-submodule > even with a faulty lua integration (still forking... but huge > performance boost anyway): > http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051 I don't see how that is relevant, but I'm certain the same can be done with Ruby. > As you can see a lua integration would increase the git binary with > 300kb. And my patch would increase it 49Kb. IMO the problem with lua is that it's too simple, it's syntax doesn't resemble c, perl, python, shell, or ruby, it's just weird. Also, it's much less popular, it's not as powerful, and there isn't a big community involved with Git like with Ruby. Sure, for a couple of simple scripts lua bindings would be great, but for the future, better maintainability, and to grab future developers, Ruby is simply a better option. -- 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
