Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: mca1001 [...] users.sourceforge.net
Cc:
AdminCc:

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



Subject: "fatal: Not a git repository: $valid_workingcopy\n" under Dist::Zilla::Plugin::@blah
Hi Philippe, Thank you for writing Git::Repository. It made App::MediaWiki2Git much simpler. The bug in short: Git::Repository->new is not defending itself against changes to $/ ($INPUT_RECORD_SEPARATOR or $RS). This causes pathnames based on data returned from "git rev-parse --gitdir" etc. to have a trailing \n and that trips the sanity check. This happens when Dist::Zilla::Plugins::GitFmtChanges v0.003 reads git-log with local $/="\n\n"; then calls DZP:Git::DescribeVersion, which calls Git::DescribeVersion, which will take advantage of Git::Repository when installed. I have only seen the bug triggered with this combination of modules. The attached file is a hackpatch to my installed copy, which makes the problem go away but may not be an ideal solution. It also changes the sanity check error message three ways, - to make it less like the built-in Git error. This should make "search for similar error messages in existing bug reports" easier. - add quotes round the offending data. This makes trailing \n more obvious. - show the two values being compared, since this is an A != B error. Sorry, I didn't stop to think which is Expected and which is Got. I will also file tickets for these other modules... I'm sorry I didn't write a test to run under changed $/ , but I'm already shaving fractal yaks! Thanks again for your work, -- Matthew
Subject: git-rep.diff
diff --git a/lib/perl5/Git/Repository.pm b/lib/perl5/Git/Repository.pm index 2a7e3ab..c842e3b 100644 --- a/lib/perl5/Git/Repository.pm +++ b/lib/perl5/Git/Repository.pm @@ -11,7 +11,7 @@ use Scalar::Util qw( looks_like_number ); use Git::Repository::Command; -our $VERSION = '1.22'; +our $VERSION = '1.22001'; # a few simple accessors for my $attr (qw( git_dir work_tree options )) { @@ -56,6 +56,7 @@ sub import { sub new { my ( $class, @arg ) = @_; + local $/ = "\n"; # create the object my $self = bless {}, $class; @@ -139,7 +140,7 @@ sub new { my $gitdir = eval { _abs_path( $self->run(qw( rev-parse --git-dir )), $cwd ) } || ''; - croak "fatal: Not a git repository: $self->{git_dir}" + croak "fatal: Cannot find the git repository: '$self->{git_dir}' ne '$gitdir'" if $self->{git_dir} ne $gitdir; # put back the ignored option
On Wed Oct 12 04:41:40 2011, MCAST wrote: Show quoted text
> This happens when [...] with local $/="\n\n" [...] calls > Git::DescribeVersion, which will take advantage of Git::Repository
Hi again, I forgot to mention, in case relevant, that G:DV is calling with Git::Repository->new(work_tree => '.') HTH, -- Matthew
Thank you very much for your report. I missed this ticket (EOOMUCHMAIL), and only found about it a few minutes ago, while cleaning up the Git-Repository queue from another bug. I agree that Git::Repository is vulnerable to changes to $/. This is probably the case everywhere readline() (or <>) is used. A more general fix would probably to restore $/ locally in the final_output() method of Git::Repository::Command. I'll look into it (and make yet another release... I should have looked at my RT queue *before* doing the 1.23 release ;-) Regards, -- BooK
Subject: Re: [rt.cpan.org #71621] "fatal: Not a git repository: $valid_workingcopy\n" under Dist::Zilla::Plugin::@blah
Date: Thu, 8 Dec 2011 22:20:16 +0000
To: Philippe 'BooK' Bruhat via RT <bug-Git-Repository [...] rt.cpan.org>
From: Matthew Astley <mca1001 [...] users.sourceforge.net>
(Hmm, I postponed instead of sending, but it looks finished. Presumably there is a broken sentence in here I didn't see - sorry) On Sun, Dec 04, 2011 at 11:26:08AM -0500, Philippe 'BooK' Bruhat via RT wrote: Show quoted text
Show quoted text
> Thank you very much for your report. I missed this ticket > (EOOMUCHMAIL), and only found about it a few minutes ago, [...]
No worries, the module from which $/ leaked (tickets linked) was already fixed, and released promptly. Show quoted text
> [...] A more general fix would probably to restore $/ locally in the > final_output() method of Git::Repository::Command.
Yes. I'm afraid I didn't look very far once I found the two ends. Mutters: there ought to be a way to... localise or replace? these shared globals... for a block or entire calling package, or at least per individual handle. IO::Handle (for 5.10.1) explicitly doesn't support per-object $/ I guess it wouldn't be hard to make a wrapper object that did it per call, but like I said about the fractal yak shaving. Good luck with that mail, -- Matthew