Problems using perl's Git.pm module

Hello folks,

I am trying to use perl's Git.pm module, but for some reason, it keeps bailing out:

  jw@raven:~/testrepos> git st
  # On branch master
  nothing to commit (working directory clean)
  
  jw@raven:~/testrepos> ./test.pl
  # On branch master
  nothing to commit (working directory clean)
  status failed w/ code 1 at ./test.pl line 9
  
  jw@raven:~/testrepos> cat test.pl
  #! /usr/bin/perl
  
  use strict;
  use warnings;
  use Git;
  
  my $repo = Git->repository (Directory => '.');
  git_cmd_try { $repo->command_noisy('status') }
                       '%s failed w/ code %d';
  
  print "Never reach this line\n";
  
  jw@raven:~/testrepos> 

Any ideas why the status command keeps bailing out on an entire clean repository?

On Thu, Dec 2, 2010 at 12:40, Josef Wolf <jw@raven.inka.de> wrote:

Why are you using it? It's for internal use only.

Couldn't you use one of the Perl Git wrappers on the CPAN?

Ævar Arnfjörð Bjarmason wrote:

Where do you get that from?  (Not sure whether it's true, just curious.)

This is still a reasonable suggestion, certainly.

On Thu, Dec 2, 2010 at 17:19, Jonathan Nieder <jrnieder@gmail.com> wrote:

It, like our internal C is subject to change at any time. It's not intended for external use.

Yes, it really is much better to use the CPAN modules that wrap Git. We might even want to use them ourselves someday.

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

That is not a valid question nor answer, I am afraid.

It probably is showing that perl/Git.pm is underdocumented. We should make it possible if not trivial for people who want to write the next great git-svn.perl or whatever that uses the module to interact with the repository.

I don't understand why the Josef's scriptlet passes Directory to the initialization code. Is it working with a bare repository?

On 2 December 2010 18:46, Junio C Hamano <gitster@pobox.com> wrote:

So you are saying that it is for more than internal use?

Yves

demerphq wrote:

I assume so. I had guessed the same thing (that it is meant to be generally useful), based on the following:

 - it is installed to be usable with a simple "use Git"
   automatically

 - "perldoc Git" tells me that this module gives Perl scripts an easy
   way to interface the Git version control system, not that it is an
   implementation artifact

 - tools like "git svn" were not historically part of core git, and
   usage by them was not exactly internal use.

Hope that helps. Jonathan

On 2 December 2010 19:14, Jonathan Nieder <jrnieder@gmail.com> wrote:

Well that is true. But im not sure that is a good reason.

Any perl module, or script, or podfile installed in a place that perldoc knows about is available to perldoc.

Well, the counter  arguments are:

No back-compat layer for older gits. Tight binding to a particular git
- no availability of upgrades independent of upgrading git. No
availability or review of the module on the standard venues for doing
so for Perl modules. CPAN, CPANTESTERS, smoke reports, etc.

And well the line:

# Totally unstable API. $VERSION = '0.01';

STRONGLY suggests that the module should not be used by code outside the Git package itself.

Cheers, yves

Git's internal perl interface still does not have a stable API, and meanwhile CPAN has a number of modules to fulfill the need for a perl git interface. The line

	# Totally unstable API.
	$VERSION = '0.01';

in the source makes this clear enough, but users who just looked at git-svn.perl and then tried "perldoc Git" would not notice. Add a note to the manual to warn the reader.

Inspired-by: Yves Orton <demerphq@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
demerphq wrote:

So how about something like this patch, to start?

Jonathan Nieder <jrnieder@gmail.com> writes:

Ok.  We may probably want to reduce the repetition of "easy", though.

Junio C Hamano wrote:

Yes. ---

On Thu, Dec 02, 2010 at 07:41:00PM +0100, demerphq wrote:

I don't understand this one. Why do you need independent upgrades here? Since Git.pm comes with git core, the installed version of Git.pm should always match the installed version of git.

A module on CPAN has better tests for perl integration. A module in git-core has better tests for git integration.

You trade one for the other. The question is which is more critical. IMHO, git-integration is more critical.

On 3 December 2010 09:38, Josef Wolf <jw@raven.inka.de> wrote:

Because in my experience coding a tool against a particular version of Git.pm basically means that tool has to be on the same git version or higher than the version you coded against.

There is no easy/safe way to update Git,pm to provide a consistent interface to older gits.

A CPAN module would be automatically tested by the CPANTESTERS community against whatever git people happened to have lying around, and those tests would necessarily occur on a myriad of systems, and when failures occurred they would be automatically registered in CPAN rt bug tracking system, and available in various summarized and detailed forms from multiple locations.

Those test results and integration efforts would be automatically fed back to the module author, be publicly available on several websites, including via CPAN itself, and if it should happen that the p5p group were to somehow break Git.pm somehow we would know about it, and be able to fix perl itself without Git.pm having to change. Admittedly this is unlikely given the nature of the code.

So really, by tightly binding the package to git all that you guarantee is that the version of Git.pm installed by git will work with the git you have installed. It does not say that any program written against that version of Git.pm will continue to work on a later version, or that people stuck on a older version of git will be able to use it.

cheers, Yves

demerphq <demerphq@gmail.com> writes:

No.

Imagine you were adding a new function to git-svn.perl and wanted to know why your addition that looked somewhat similar to what Josef sent did not work as you expected.

We should be able to answer such a question, don't you think? People often seem to badmouth this list as git develper's list that is unfriendly to end users. I don't think that is true, but even if that were true (or especially if that were true), shouldn't we be try to be friendly at least to a potential developer who tries to learn and use Git.pm module?

On 2 December 2010 19:18, Junio C Hamano <gitster@pobox.com> wrote:

Certainly. My question purely had to do with whether it is for internal use or not.

The reason I asked is that I don't think it is for external use, and wanted to make sure you agree.

cheers, Yves

On Thu, Dec 02, 2010 at 02:23:32PM +0100, Ævar Arnfjörð Bjarmason wrote:

1. It is always available whenever git is available, so I don't need to
   search/install additional packages just to hack some scripts. If you
   have to support multiple distros/OS'es, it starts getting a PITA to
   find out what/how to install those additional packages.

2. Since it is used by the core developers, I assumed that it would be
   more robust than some third-party wrappers.

3. Since it is bundled with git, I'd not expect any version mismatches.
   With a third-party wrapper, version mismatches are much more likely.

Which one would you suggest?

Josef Wolf wrote:

Judging from [1], Git::Wrapper might be worth trying.

That said, if you have more questions or any ideas for Git.pm, they would be welcome. That is when the lack of declared stable API can come in handy. ;-)

[1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Perl

Josef Wolf <jw@raven.inka.de> writes:

I take it that you have "alias.st.cmd = status".

Observe what this gives you:

    $ git st; echo $?

If you are running pre-1.7.0 version of git, I think "git status" was a synonym to "git commit --dry-run" and exited with non-zero status to signal the caller that there is nothing to commit, which is...

...consistent with what we see here.

On Thu, Dec 02, 2010 at 09:51:50AM -0800, Junio C Hamano wrote:

Yes, I'm still strongly tied to svn ;-)

1

It's 1.6.4.2, so I guess you're right.

Thanks!