3 ms·

Considering Git is written primarily in C, it's not that surprising, and the fact that they're no longer using the canonical Git implementation but a Ruby-based

by kylec 18y ago

Considering Git is written primarily in C, it's not that surprising, and the fact that they're no longer using the canonical Git implementation but a Ruby-based clone makes me worried about future incompatibilities and bugs. I don't know Ruby, but wouldn't the better solution be some variant of C's exec call that executes the instruction directly without interpreting the shell string? This would reduce some parsing overhead and still allow the site to use the official version of Git.

tptacek 18y ago
Not really. I mean, with the backtick, you're doing 2x the execve's (you're exec'ing the shell), but it's still just very slow to fork and exec another process to get things done for you. The real solution to calling C code from within Ruby is to call into the C code, either using DL/Win32API (tricky but doable) or by writing Ruby bindings.
- schacon 18y ago
  Unfortunately, the implementation of Git makes writing bindings to it - in Ruby or Python or something similar -very problematic. None of it is really meant to be a long running process, so it will exit program execution on lots of different errors, etc. There was a Google Summer of Code project that tried to address this 'libification' problem, but it did not get very far - at least, not far enough to do what something like GitHub needs to do. http://code.google.com/soc/2007/git/appinfo.html?csaid=5DB940E4533E058B http://code.google.com/soc/2007/git/appinfo.html?csaid=5DB94... Actually, the Ruby implementation for most of these operations is pretty fast (though not as fast as C) and the object specs are incredibly slow changing. The commands change around a lot, but the objects themselves are pretty simple and have not changed much in years. Doing this is far less prone to git changing than depending on command line (or possibly even binding) calls.

by kylec 18y ago

tptacek 18y ago

Not really. I mean, with the backtick, you're doing 2x the execve's (you're exec'ing the shell), but it's still just very slow to fork and exec another process to get things done for you. The real solution to calling C code from within Ruby is to call into the C code, either using DL/Win32API (tricky but doable) or by writing Ruby bindings.

schacon 18y ago
Unfortunately, the implementation of Git makes writing bindings to it - in Ruby or Python or something similar -very problematic. None of it is really meant to be a long running process, so it will exit program execution on lots of different errors, etc. There was a Google Summer of Code project that tried to address this 'libification' problem, but it did not get very far - at least, not far enough to do what something like GitHub needs to do. http://code.google.com/soc/2007/git/appinfo.html?csaid=5DB940E4533E058B http://code.google.com/soc/2007/git/appinfo.html?csaid=5DB94... Actually, the Ruby implementation for most of these operations is pretty fast (though not as fast as C) and the object specs are incredibly slow changing. The commands change around a lot, but the objects themselves are pretty simple and have not changed much in years. Doing this is far less prone to git changing than depending on command line (or possibly even binding) calls.