Hi, On Sun, 13 Jul 2008, Shixin Zeng wrote:
> As you all know that git-svn on windows is a CPU hog, due to extensive > fork/exec. I want to then write a binding for the git functions, such > that we can use them without fork/exec. I did some experiments last > night, but there are still some problems I can't solve. > > Rationale: > Most of git commands (builtins) are implemented in functions cmd_*. > Calling the binding of these cmd_* functions would be equivalent to > invocation of the corresponding git commands, which makes the > transition from current implementation of git-svn and Git.pm easy. > > Problem: > Some cmd_* output the information to STDOUT, so the only way to get > the results is redirecting the STDOUT to anther file. I googled online > and found a couple of ways to redirect STDOUT in perl, but none of > them works for cmd_*, they do work for pure perl functions though. > > Resolution: > a). Find a way to redirect STDOUT in cmd_* to a file or ideally to a > variable or to an in-memory file. > b). modify git source to add a hook for redirection of STDOUT. > > What I did is: > 1) rename die() to git_die() because this one conflicts with the perl > builtin function. > 2) use swig [0] to create the perl binding to all builtin cmds. > 3) test the perl binding. > > Any comments? > > [0] http://www.swig.org/ While I commend your efforts, I have a strong suspicion that you do not know what you are getting yourself into. libgit.a is _certainly_ not a library in the classic sense. It is just a convenience to build one-shot programs, i.e. programs that run, do one thing, and then exit(). The exit() will take care of quite a few things, and the fact that we have a gazillion global variables that are automatically initialized to all-zero at the start of a program (and are actually expected to be initialized that way by libgit.a), does not help. If you are serious about the effort, I suggest something completely different: use 'git fast-import'. This will require major surgery to git-svn, and probably even rewrites of major parts of it, but in the long run, it is the Right Thing To Do. Of course, this will require you studying git-svn in detail, so that you understand what it does, and when. And it will require you to study what fast-import actually does, and how to use it to commit incrementally. The upside would be that the change would benefit Windows and other users alike, as in the ideal case, only two fork() would be necessary: one to read the tree of the current ref, and then a single fast-import. Hth, Dscho
