On Sat, Jun 8, 2013 at 12:15 PM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote: > >> > There are a lot of static variables in builtin/ (and outside too), >> > which make it non-entrant, or at least not safe. >> >> So? >> >> > fork provides a process space isolation, some depend on that. >> >> Process space isolation from what? > > Manipulation of global variables. Here are a few examples off the top of > my head: > > Try running "git diff" from your Ruby hook, then try running "git > diff-files" within the same process. I believe the latter will start > respecting porcelain diff config like diff.mnemonicprefix. To clear > state you need to reset a list of global variables back to their initial > states (some of which are the BSS-default zero, but some of which are > not). > > Try running "git log" followed by another "git log". The log family of > commands does not clear its marks from the commit objects, since it > expects to exit after the traversal. The second log will sometimes give > wrong answers if its traversal overlaps with the first (e.g., commits > marked SEEN or UNINTERESTING that should not be). You can add a call to > clear them at the end of the process, but that does not cover any cases > where we die(). > > These are problems that can be solved. But there is a lot of work > involved in finding these subtle bugs and coming up with fixes. I think > you would be better off working on an implementation of git that was > designed from scratch to work in-process, like libgit2. So you are in favor of never ever having an official Git library. Got it. > libgit2 doesn't have feature parity with regular git yet, but there are > many clients based around it that use the library internally for speed, > and then exec regular git to fill in the gaps. There's a reason why the Git project doesn't use libgit2, and for the same reason the official Ruby scripts should not use it. As history indicates, the Git project will never have any pressure to fix it's re-entrancy and re-run issues, so these issues will remain there forever. Only if you allow code that exposes those issues will there ever be any pressure to fix them. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html