threads / discuss / 16031

Problem with Git.pm bidi_pipe methods

Subject: Problem with Git.pm bidi_pipe methods

## tl;dr

3 messages between Oct 24, 2008 and Nov 23, 2008.

replies: 2people: 3as markdown or json

Philippe Bruhat (BooK)· Oct 24, 2008, 00:14 UTC · lore
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))
Christian Jaeger· Oct 28, 2008, 09:12 UTC · re: Philippe Bruhat (BooK) · lore

Re: Problem with Git.pm bidi_pipe methods

Philippe Bruhat (BooK) wrote:
Show 7 quoted lines
> 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).

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

nadim khemir· Nov 23, 2008, 19:03 UTC · re: Philippe Bruhat (BooK) · lore

Re: Problem with Git.pm bidi_pipe methods

On Friday 24 October 2008 02.14.46 Philippe Bruhat (BooK) wrote:
> 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
> ...

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.

← back to recent threads