Skip Menu |

This queue is for tickets about the Git-Repository CPAN distribution.

Report information
The Basics
Id: 106330
Status: resolved
Priority: 0/
Queue: Git-Repository

People
Owner: Nobody in particular
Requestors: TIMB [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: I'd like to be able to run interactive commands via Git::Repository
I'd like to be able to run interactive commands via Git::Repository to make use of the many features like setting cwd, git command, environment, fatal etc. I understand it wouldn't be able to control input or output, but that's ok. For example: $status = $repo->run("merge", ..., { interactive => 1 }) or $status = $repo->run_interactive("merge", ...) I presume this would require extending System::Command, e.g. to not alter stdin/stdout/stderr.
A rather hackish quick-fix that could still be useful would be to add a system() method that simply calls the built-in system() after the appropriate chdir and localized %ENV alterations. Something like: $gitrepo->system($gitrepo->git_cmd, @args); (and chdir back afterwards, naturally). Just a thought.
On Mon Aug 10 10:54:20 2015, TIMB wrote: Show quoted text
> I'd like to be able to run interactive commands via Git::Repository to > make use of the many features like setting cwd, git command, > environment, fatal etc. I understand it wouldn't be able to control > input or output, but that's ok.
I'm not sure I understand the use case. What do you mean by "interactive"? Things like the interactive version of some commands (rebase, add)? Or something else? -- BooK
Show quoted text
> What do you mean by "interactive"? > Things like the interactive version of some commands (rebase, add)? > Or something else?
Yes. Anything that would cause git to want to start an editor, for example.
On Mon Aug 10 17:22:18 2015, TIMB wrote: Show quoted text
>
> > What do you mean by "interactive"? > > Things like the interactive version of some commands (rebase, add)? > > Or something else?
> > Yes. Anything that would cause git to want to start an editor, for example.
OK, but then I don't see what's missing from Git::Repository to do that. You can invoke git rebase, for example, and define your own EDITOR environment variable like this: $r->run( rebase => '-i', 'master', 'topic', { env => { EDITOR => ... } } ); I see git rebase also has a --exec option, so you can even have more control on what's going to be run. Maybe some of the other commands also have such an option. Git::Repository should be able to run any git command. run() will collect stdout and stderr for you, while command() will hand you the filehandles. What you do with them is up to you. Also, sometimes Git itself figures out it's not attached to a terminal, and behaves differently. See https://metacpan.org/pod/distribution/Git-Repository/lib/Git/Repository/Tutorial.pod#Process-the-output-of-git-shortlog for an example. Do you have a more specific example of the git commands you're trying to run, and how it does not behavas as you expect? Thanks, -- BooK
For example, in a repo where "git rebase -i"would open an editor, try this: perl -MGit::Repository -we 'Git::Repository->new->run("rebase","-i")' It hangs. Running pstree I see: perl,13354 -MGit::Repository -we Git::Repository->new->run("rebase","-i") └─git,13366 rebase -i └─git-rebase,13367 /usr/libexec/git-core/git-rebase -i └─vim,13440 /home/tim/trunk/comp/support_stripes/.git/rebase-merge/git-rebase-todo
On Thu Aug 13 06:04:18 2015, TIMB wrote: Show quoted text
> For example, in a repo where "git rebase -i"would open an editor, try > this: > > perl -MGit::Repository -we 'Git::Repository->new->run("rebase","-i")' > > It hangs. Running pstree I see: > > perl,13354 -MGit::Repository -we Git::Repository->new->run("rebase","- > i") > └─git,13366 rebase -i > └─git-rebase,13367 /usr/libexec/git-core/git-rebase -i > └─vim,13440 > /home/tim/trunk/comp/support_stripes/.git/rebase-merge/git-rebase-todo
And what would be the expected behaviour? If the perl program is attached to a terminal (-t STDIN is true), then effectively run the EDITOR and wait until it's done? And if not attached to a terminal, just fail? Would that work for you? The fail case is easy: delete EDITOR from %ENV if -t STDIN is false. $ perl -Ilib -MGit::Repository -e '$r=Git::Repository->new; delete $ENV{EDITOR}; $r->run( qw( rebase -i master ) )' fatal: Terminal is dumb, but EDITOR unset Could not execute editor at -e line 1. If running in a terminal, then running system() would work. (And be portable, I think. At least more than trying to reattach the filehandles in the right place.) If you want to run the "interactive" command in a non-interactive way, i.e. have a program process the content of the file generated by git before handing control back to git, one way would be to put the whole command line in $ENV{EDITOR}. Sounds fragile and ugly, but I wonder if there are other ways to keep git waiting for the EDITOR to finish, while replacing the file by your own version (and avoiding race conditions). * * * I wonder if adding an 'interactive' option to System::Command is not the simplest and most generic way to handle this situation (at least when trying to handle the first two cases): when interactive is true, then die (in System::Command) if -t is false, and otherwise call system() instead of the internal spawn command. What do you think?
On Thu Aug 13 08:12:54 2015, BOOK wrote: Show quoted text
> > I wonder if adding an 'interactive' option to System::Command is not > the simplest and most generic way to handle this situation (at least > when trying to handle the first two cases): when interactive is true, > then die (in System::Command) if -t is false, and otherwise call > system() > instead of the internal spawn command. >
System::Command version 1.114 now has an 'interactive' option.