8 ms·

Curious, how would you do it? (disclaimer: I work at GitLab, not on this project though)

• revelation 9y ago
  Someone mentioned libgit2, and that is a good first step fix. There is no need to launch a process that calls libgit2 when you can call high-level libgit2 functions yourself. That already eliminates this problem entirely, along with all the other ickiness that comes with running command line tools programmatically. But ultimately this is the main Git interface for the remainder of the site, and it is apparently already sharded so only has to deal with a limited number of repositories. You can use libgit2 on a low-enough level that you can just keep and mutate repository state in memory. Something like a ref exists should be just a hash table lookup, and there are a bunch of other commands where gains can be had when you are not starting from scratch on every API call. (This is what github is doing. They started out with grit, which was some parts of Git reimplemented in Ruby and then launching git for heavy-weight stuff. Nowadays they use rugged, the ruby bindings for libgit2.)
• Animats 9y ago
  Use something like boring old FCGI. FCGI spawns off N workers, which process one request at a time. If a worker crashes, it's restarted. Workers are usually restarted every once in a while to deal with any memory leaks. Read-only requests with no security implications get done by in the worker process, which has read permissions for public files. More complex requests spawn a Git client program. It would be so uncool, though.
• cstrahan 9y ago
  In their case, why not stat the path directly?
  • masklinn 9y ago
    Packs, most likely. On my main $work local repo, I have 27 refs and 22240 packed refs.
• rakoo 9y ago
  If forking to a process is not good enough, I'd use a native, read-only library such as https://github.com/speedata/gogit https://github.com/speedata/gogit