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. However since Microsoft
working with libgit2 on a Visual Studio plugin this it might be that the
need for windows support decreases.
> >> > 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".
> > 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
> > 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:
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):
As you can see a lua integration would increase the git binary with
Med vänliga hälsningar
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