On Jul 13, 2:34 pm, Johannes Schindelin <[EMAIL PROTECTED]>
wrote:
> Hi,
>
>
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.
>
Sure, I'm new to git implementation.
> 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.
>
I understand that libgit.a is just an archive of a bunch of object
files. I've noticed that there are a lot of global variables in non-
builtin commands. They need to be removed if I keep going on my way.
> 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.
>
It doesn't sound an easy job to me then. I haven't touched perl code
for a couple of years and I don't have much time. However, I'll try to
get myself familiar with this, when I find some time.
Thanks.
> Hth,
> Dscho
