Hi,

To be able to call commit-tree from a Perl program, I had to use
command_bidi_pipe() to pass the message on standard input, and get the
new commit id on standard output. The only problem I have is that the
method doesn't work (or at least, doesn't work like the other
command_... methods).

    sub command_bidi_pipe {
        my ($pid, $in, $out);
        $pid = open2($in, $out, 'git', @_);
        return ($pid, $in, $out, join(' ', @_));
    }

First, it calls git in the current working dir, when all the other
command_... methods do the appropriate chdir depending on the Git object.

Second, it can't be used as a method, since $self is not removed from @_
before calling open2, leading to errors such as this one:

    git: 'Git=HASH(0x82f898c)' is not a git-command. See 'git --help'.

Third, no access is given to STDERR (open3 may help).

I'm very sorry to complain without proposing a patch.

I think solving the current directory problem is probably going to be
difficult with open2/open3, since open2 does the fork+exec, whereas Git.pm
handles the fork+chdir+exec itself for the other command_...  methods.
And so there is no room to chdir when calling open2.

-- 
 Philippe Bruhat (BooK)

 Treat those you outrank well... you never know when they will outrank you.
                                                 (Moral from Groo #7 (Image))
--

[ message continues ]

Not really an answer on how to fix Git.pm, but: you may want to subclass 
Git.pm and add your own methods ad interim. See the thread "[PATCH] 
Git.pm: do not break inheritance" [1] about how to subclass (I see that 
this patch is actually in {next,pu} already, and anyway you can use the 
runtime patching approach I described there).

That approach of using subclasses has two benefits: (a) it will tend to 
make your code work with various versions of Git (i.e. one without a 
fixed command_bidi_pipe method), and (b) you will be much more free to 
extend the code. The drawback will be of course that your inventions 
won't necessarily make it back to Git.pm, but I'm tempted to think that 
some innovation taking place before settling on what should make it back 
to Git.pm (or, if incompatible, possibly a new Git.pm) would be worthwhile.

For an actual example in writing Git subclasses see "[ANNOUNCE] intergit 
repository-linking tool (early release)" [2].

Christian.

[1] http://article.gmane.org/gmane.comp.version-control.git/98568
[2] http://article.gmane.org/gmane.comp.version-control.git/99197

--

[ message continues ]

Hi Philippe, I'm going to take over the Git.pm maintenance and I'd be happy to 
discuss this problem with you (you know whwere to find me right ;) and I'll 
be happy to hear your suggestions too.

Nadim.
--

[ message continues ]