To complete the Git::Raw backend I'm currently writing for Git::Database, I need to implement the put_object method for the Git::Database::Role::ObjectWriter role.

git_odb_write looks like the method that I need.

If I want to improve on the default implementation of hash_object, I could probably make use git_odb_hash too.

Thanks in advance.

I'd like to control the workdir. Maybe something like this:

$repo -> workdir( $new_workdir_path );

Have you seen an example of how to actually perform something similar to git-merge using libgit2. I've searched high and low and can't find anything concrete.

As I understand it, Diff->merge() only merges two diffs for the purpose of doing a 3-way diff (I think). But before you can do that, you probably need to call git_merge_base to figure out which trees to compare.

Hello, I'm playing a bit with Git::Raw (I like it), but it seems git rev-parse is missing, is that correct?

GitLab devs have already worked around in their code:

https://gitlab.com/gitlab-org/gitlab-ce/issues/3265#note_2527976
https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/2

but the underlying bug is still present in Git::Raw version of libgit2 - basically it should be using case insensitive comparison on the 'WWW-Authenticate' header so that it still works with a server returning 'Www-Authenticate'.

Here's the upstream commit that fixes libgit2:

libgit2/libgit2@31a7637

Please refresh or cherry-pick that fix so it's included in next CPAN version.

Thanks in advance for any assistance you can provide. I am trying to figure out how to take changes pulled down from a remote, and merge them into the current HEAD and not having much luck. It seems like the features required are implemented, but I'm unsure of how to actually make it happen. I've managed to fetch the upstream differences, and I can see the ref for the branch I am targeting, but I'm stuck because when using Git::Raw::Repository::lookup to get the reference by id it is returned as a Commit object which can't be used in Git::Repository::merge. I've tried a few different things without much luck, and my searching around hasn't yielded much of an explanation of how this is accomplished in libgit2 generally.

Here is a snippet of my current code. The fetch is working and ls returns a hashref as would be expected according to the documentation.

    $rem->connect("fetch");
    $rem->download;
    $rem->update_tips;
    my $refs = $rem->ls;
    foreach my $ref ( keys %{$refs} ) {
        if ( $ref =~ $pat ) {
            my $id = $refs->{$ref}->{'id'};
            my $success = try {
                my $merge_source = $self->repository->lookup($id);
                my $merge = { favor => 'theirs' };
                my $checkout = { checkout_strategy => { force => 1 }};
                $self->log("debug","merging %s into current HEAD",$id);
                $self->repository->merge($merge_source,$merge,$checkout);
                return $id;
            } catch {
                $self->log('crit',"failed to merge $ref: %s", $_->message);
                return undef;
            };
            $self->log('warn',"merger of upstream changes was unsuccessful due to one or more errors") if not $success;
        }
    }
    $rem->disconnect;
    return $rem;

The error I am receiving with this block of code is quite simply:

2014-09-08 21:27:15.000000 +0000 crit  desman project: failed to merge refs/heads/devel: ref is not of type Git::Raw::Reference

Since this Commit is being returned from a list of refs, I would imagine it would be ready for use [as a reference], but that doesn't seem to be the case. It seems like if I use the lookup method of the Reference object I get undef. Is there anyway when using Git::Raw::Repository::lookup to specify the object type to be returned or some way to "convert" the Commit object into a Reference? Am I going about this all wrong or missing something that should be obvious?

I have a project I am working that watches a working copy of a git repo and automates the process of pushing to multiple commits whenever a change is made. When the project was started, we were running perl v5.10 on RHEL 6. However, it came to my attention that 5.10 doesn't support the unicode_strings feature implemented in 5.12 or greater, and I am now in the process of converting to a newer version of perl (5.16 through SCL).

This has required me to start refactoring older Git stuff to use Git::Raw because the original module doesn't seem to be available through SCL or CPAN.. I have to say, so far, this is a much more elegant solution. That said I've hit a snag with regard to git push that may be an issue with my code but seems more likely to be the behavior of the Git::Raw::Push module.

Git::Raw::Push requires that you pass a valid refspec string. The examples shown illustrate a single head push which is great and seems to work when targeting just a single head:

my $refspec = "+refs/heads/$head:refs/remotes/$remote/heads/$head";
$push->add_refspec($refspec);

However using the syntax outlined in the git documentation to indicate all heads returns an error indicating that the spec is not valid. The strange thing is that if you use the Git::Raw::Refspec::string() method on a remote that doesn't have a custom refspec, the return value is exactly what I am passing which is being rejected with the error Not a valid reference 'refs/heads/*'

my $rem = $self->remote($remote);
my $spec = $rem->refspecs->string;
$push->add_refspec($spec);

The returned respec is +refs/heads/*:refs/remotes/origin/heads/* which SHOULD be a valid refspec according to the documentation I am reading. My low level familiarity with the internals of git is limited, so it's possible this is a problem between the computer and chair. Is there anything I'm missing? Please let me know if you need any further information from me.

the following code results in SEGV crash on write_tree:

my $index = Git::Raw::Index->new();
$repo->index($index);
my $tip_tree = $branch->peel('tree');
$index->read_tree($tip_tree);
$index->add_frombuffer($msg_filename, "msg 1\n");
my $tree = $index->write_tree();

A workaround that works is to re-read the index from the repo:

my $index = Git::Raw::Index->new();
$repo->index($index);
my $tip_tree = $branch->peel('tree');
$index->read_tree($tip_tree);

$index = $repo->index();

$index->add_frombuffer($msg_filename, "msg 1\n");
my $tree = $index->write_tree();

So, this behavior either needs to be investigated, or documented in POD

If user's ~/.gitconfig has the following lines:

[diff]
    mnemonicprefix = true

then t/09-diff.t fails, because the usual "a" and "b" path prefixes are replaced by something like "i" and "c":

 #   Failed test at t/09-diff.t line 41.
 #          got: 'file => diff --git c/diff i/diff
 # new file mode 100644
 # index 0000000..6afc8a6
 # --- /dev/null
 # +++ i/diff
 # hunk => @@ -0,0 +1 @@
 # add => diff me, biatch
 # '
 #     expected: 'file => diff --git a/diff b/diff
 # new file mode 100644
 # index 0000000..6afc8a6
 # --- /dev/null
 # +++ b/diff
 # hunk => @@ -0,0 +1 @@
 # add => diff me, biatch
 # '

Possible solution: explicitly set this config option to false for test git repository.

I'm running a dzil test on Debian testing with gcc 8.3.0 and I get the following warning:

./xs/Walker.xs: In function ‘XS_Git__Raw__Walker_push_range’:
./xs/Walker.xs:135:4: warning: ‘strncpy’ output truncated before terminating nul copying 2 bytes from a string of the same length [-Wstringop-truncation]
strncpy(range + GIT_OID_HEXSZ, "..", 2);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The flag exact_match_only is not listed in POD for Git::Raw::Repository->diff()

The following code generates a diff based on SHA checksums mismatch only:

    my $diff = $old_tree->diff(
        {'tree' => $new_tree,
         'flags' => {
             'exact_match_only' => 1,
         },
        });

Probably the same issue like in #20

Hi,

in deps, there is a number of "external" libraries included that an average LInux system already has. In Debian, we take special consideration not to use "convenience copies" of libraries that upstreams bundle with their software releases. This especially applies to libz, which needs security updates quite often.

The build process of Git::Raw should detect that the system has those libs installed as system packages and use those instead of the local convenience copies. The build-process should, in this case, still complete when one zaps the entire deps directory.

The following patch makes this behavior hard-coded, but removes all usage of the convenience libs, so "your" version should be a bit smarter than this, sledge-hammer approach.

--- a/Makefile.PL
+++ b/Makefile.PL
@@ -250,12 +250,7 @@ if ($Config{usethreads} && !$is_sunpro)
 my @deps = glob 'deps/libgit2/deps/{http-parser,zlib}/*.c';
 my @srcs = glob 'deps/libgit2/src/{*.c,transports/*.c,xdiff/*.c,streams/*.c}';
 
-if ($is_msvc) {
-       push @srcs, 'deps/libgit2/src/hash/hash_win32.c';
-}
-elsif (!$library_opts{'ssl'}{'use'} && !$is_osx) {
-       push @srcs, 'deps/libgit2/src/hash/hash_generic.c';
-}
+$lib .= ' -lgit2';
 
 # the system regex is broken on Solaris, not available on Windows
 if ($is_windows || $is_solaris) {
@@ -333,7 +328,7 @@ my %WriteMakefileArgs = (
     "Getopt::Long" => "2.35"
   },
   "DISTNAME" => "Git-Raw",
-  "INC" => "-I. -Ideps/libgit2 -Ideps/libgit2/src -Ideps/libgit2/include -Ideps/libgit2/deps/http-parser -Ideps/libgit2/deps/zlib",
+  "INC" => "-I. ",
   "LICENSE" => "perl",
   "MIN_PERL_VERSION" => "5.006",
   "NAME" => "Git::Raw",

Recently pulling from cpan it seems not all package contents are being compiled.

root@drop:/run# uname -r
2.6.32-504.8.1.el6.x86_64
root@drop:/run# cpan Git::Raw
..........
# build process
..........
  JACQUESG/Git-Raw-0.51.tar.gz
  /usr/bin/make install  -- OK
root@drop:/run# perl -c -mGit::Raw -e "print OK\n"
-e syntax OK
root@drop:/run# perl -c -mGit::Raw::Push -e "print OK\n"
Can't locate Git/Raw/Push.pm in @INC (you may need to install the Git::Raw::Push module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .).
BEGIN failed--compilation aborted.
root@drop:/run# cpan Git::Raw::Push
..........
# build process
..........
  JACQUESG/Git-Raw-0.50.tar.gz
  /usr/bin/make install  -- OK
root@drop:/run/desman# perl -c -mGit::Raw::Push -e "print OK\n"      
-e syntax OK

Based on the version info, it seems like Git-Raw-0.51 does not include the Push package. Is this intentional?

Hi,

in Debian, the compiler of most 32 bit arches (including mips, mipsel, m68k, hppa) does not have the -m32 option. The build this unconditionally fails on those arches.

Since Debian doesn't need that hack (we do things right on 64 bit arches), I have removed the option in the Debian package completely (and do hope that I didn't introduce other breakage by doing that).

Please consider being less generous with the -m32 option and only add it on arches where it is actually needed. The current method of checking for the ptrsize and then excluding arm hurts non-arm 32 bit arches.

Greetings
Marc

I'm running a dzil test on Debian testing with gcc 8.3.0 and I get the following warning:

In file included from Raw.xs:9:
ppport.h:4594: warning: "WIDEST_UTYPE" redefined
#  define WIDEST_UTYPE U64TYPE
In file included from /usr/lib/x86_64-linux-gnu/perl/5.28/CORE/perl.h:2465,
from Raw.xs:2:
/usr/lib/x86_64-linux-gnu/perl/5.28/CORE/handy.h:1064: note: this is the location of the previous definition
#   define WIDEST_UTYPE U64

Hi,

after building and make clean, a few *.inc files are left over. Those should probably be cleaned in make clean as well.

Greetings
Marc

i am able to reliably trigger a crash coming out of git_signature_free by invoking the tagger() method on a tag object. my guess is that any NULL Git::Raw::Signature in the tagger() object will trigger but i cannot programmatically create this condition in Perl.

discovered the issue working with the Git source code repository. reproduction, backtrace and kernel follow:

REPRO -

#!/usr/bin/perl -w

use Git::Raw;

my $url  = 'https://github.com/git/git.git';
my $repo = Git::Raw::Repository -> clone($url, 'crash_me', {} );

foreach my $tag ( $repo->tags )
{
  # trigger double free
  my $error_condition = $tag->tagger();
}

BT -

*** Error in `perl': munmap_chunk(): invalid pointer: 0x0000000001e90cf0 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x73f8e)[0x7fb61e5e3f8e]
/usr/lib/libc.so.6(+0x7988e)[0x7fb61e5e988e]
/usr/lib/perl5/site_perl/auto/Git/Raw/Raw.so(git_signature_free+0x11)[0x7fb61d9b27f1]
/usr/lib/perl5/site_perl/auto/Git/Raw/Raw.so(+0x3861d)[0x7fb61d92361d]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_pp_entersub+0x4bb)[0x7fb61e9e98fb]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_call_sv+0x425)[0x7fb61e96bd55]
/usr/lib/perl5/core_perl/CORE/libperl.so(+0xd5607)[0x7fb61e9f3607]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_sv_clear+0x7a0)[0x7fb61e9f4040]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_sv_free2+0x5a)[0x7fb61e9f43fa]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_leave_scope+0xce8)[0x7fb61ea18d78]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_pp_unstack+0x78)[0x7fb61e9e31a8]
/usr/lib/perl5/core_perl/CORE/libperl.so(Perl_runops_standard+0x16)[0x7fb61e9e21b6]
/usr/lib/perl5/core_perl/CORE/libperl.so(perl_run+0x30e)[0x7fb61e97336e]
perl(main+0x149)[0x400e39]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7fb61e590000]
perl[0x400e71]

$ cat /proc/version
Linux version 3.14.6-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140521 (prerelease) (GCC) ) #1 SMP PREEMPT Sun Jun 8 10:08:38 CEST 2014

I'm loving Git::Raw. But so far, it isn't clear to me how to do the moral equivalent of git checkout some_branch. None of the various checkout strategies seem to "do the right thing". In particular, they don't seem to remove files from the work dir that are not in the new tree.

I think part of the problem may be that HEAD needs to be changed to point to the new tree before starting the checkout. So perhaps a binding to git_repository_set_head() is also needed.

Or am I just looking at this in the wrong way entirely?

e.g. look at https://rt.cpan.org/Ticket/Display.html?id=83126 and be dismayed

Path::Slurp::Tiny and Path::Tiny are both excellent alternatives.

subj, so there should not be dup call after calling git_tree_entry_bypath.

It doesn't seem that the functionality of git_revparse_single() is available anywhere; it's used to find an object using any of the various formats that git allows for specifying revisions (e.g, "abc123^^", "v0.1.0:foo/bar/baz.c", "HEAD^{commit}", "some_branch").

See its documentation, and several examples of its usage here: http://libgit2.github.com/docs/guides/101-samples/

This would be handy to have.

If Git::Raw::Config->str() is asked to fetch a value using a key it does not know, a segfault ensues:

» perl -MGit::Raw::Repository -E 'say Git::Raw::Repository->discover(".")->config->str("remote.origin.url")'
[1]    18147 segmentation fault (core dumped)  perl -MGit::Raw::Repository -E 

This is with Git::Raw 0.23, and perl 5.16.2 (perlbrewed on Ubuntu precise 12.04.2).

A stack trace shows:

» gdb --args perl -MGit::Raw::Repository -E 'say Git::Raw::Repository->discover(".")->config->str("remote.origin.url")'
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/rsrchboy/perl5/perlbrew/perls/perl-5.16.2/bin/perl...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/rsrchboy/perl5/perlbrew/perls/perl-5.16.2/bin/perl -MGit::Raw::Repository -E say\ Git::Raw::Repository-\>discover\(\".\"\)-\>config-\>str\(\"remote.origin.url\"\)
Use of uninitialized value in split at /loader/0x632e88/local/lib.pm line 8.
Use of uninitialized value in split at /loader/0x632e88/local/lib.pm line 8.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff69c9972 in git_check_error () from /home/rsrchboy/.perlbrew/libs/perl-5.16.2@trunk/lib/perl5/x86_64-linux/auto/Git/Raw/Raw.so
(gdb) bt
#0  0x00007ffff69c9972 in git_check_error () from /home/rsrchboy/.perlbrew/libs/perl-5.16.2@trunk/lib/perl5/x86_64-linux/auto/Git/Raw/Raw.so
#1  0x00007ffff69ca201 in XS_Git__Raw__Config_str () from /home/rsrchboy/.perlbrew/libs/perl-5.16.2@trunk/lib/perl5/x86_64-linux/auto/Git/Raw/Raw.so
#2  0x000000000049b09c in Perl_pp_entersub ()
#3  0x0000000000493d23 in Perl_runops_standard ()
#4  0x000000000043a24a in perl_run ()
#5  0x000000000041f34d in main ()
(gdb) 

Unfortunately, I don't have the time at the moment to dig deeper into this :\

I would like to make use of Git::Raw in Gitpan, but it's missing support for lightweight tags. Gitpan needs to make a lot of tags and full, cryptographically secure, annotated tags are overkill. I realize they can be created with Git::Repository::Reference->create, but lightweight tags are not well integrated into the rest of Git::Raw.

I began to implement it, but ran into a problem. Git::Raw::Tag represents an annotated tag object. Lightweight tags do not appear to have a tag object, they're references to a commit.

Where I'm stuck in implementing lightweight tags is where they fit relative to annotated tags. Should they be left as references so Git::Raw::Reference->create_lightweight_tag() is a wrapper around Git::Raw::Reference->create("refs/tags/$name", $repo, $commit)?

Or should Git::Tag attempt to integrate them? I noticed there's a test in t/03-tag.t which appears to deliberately check that Git::Raw::Repository->tags does not see lightweight tags which is a bit confusing to command line users. I wonder if this is an undocumented quirk of git_tag_foreach, because git_tag_list does appear to return both annotated and lightweight tags, as evidenced in the libgit2 tag example.

What are your thoughts?

See subject. I am just about to send a fail report using perl 5.16.3, which apparently has a slightly older EUMM without TEST_REQUIRES support. Tests fail because File::Slurp is not available.

There is already file_mode() method, but it's not convenient, and it returns different filemodes for executables and normal files.

libgit2 has a call git_tree_entry_type which retrieves a constant indicating that the entry is a tree, a blob, or a commit. So, corresponding Perl method could be is_object_blob() and is_object_tree(), and also probably is_object_commit(), although I don't know a useful scenario for it.

The motivation is, that I need to traverse tree contents recursively, and I'm only interested in entry names and types, so reading the object content would be an overkill. But currently the only way to know the type of the entry is to either use file_mode, or to read the object from ODB.

Recent versions of libgit2 offer support for commit message trailers, such as Signed-off-by. It would be great if these interfaces could be exposed through Git::Raw, so that it isn't necessary to shell out to git interpret-trailers.

Ideally, the implementation would support multiple trailers of the same type gracefully (e.g., multiple "Cc" trailers).

I'm trying to get the list of all digests in a repository (and their object type) using Git::Raw. Basically, it would be the equivalent of git cat-file --batch-check --batch-all-objects.

As you told me, it should be doable using git_odb_foreach. So I'm opening an issue to request this functionality in Git::Raw::Odb.

Thanks,

add_frombuffer() in Git::Raw::Index accepts only a string for the new blob content. The string may be quite large, and it's beneficial to pass a string reference. Currently add_frombuffer() segfaults if I pass a reference instead of string.

Hi, I'm having fun about the module.

I get an error when I delete a reference. (running on max os x) It's reproducible by applying the patch below to the test.

diff --git a/t/06-reference.t b/t/06-reference.t
index e80aab6..82df336 100644
--- a/t/06-reference.t
+++ b/t/06-reference.t
@@ -21,4 +21,8 @@ isa_ok $head, 'Git::Raw::Commit';

 is $head -> message, "second commit\n";

+$repo -> branch('foobar06', $head);
+$ref = Git::Raw::Reference -> lookup('refs/heads/foobar06', $repo);
+$ref -> delete;
+
 done_testing;

The error message is "perl(9292) malloc: *** error for object 0x100000004: pointer being freed was not allocated".

Could you take a look when you have a chance? Thanks!

hi Jacques,

in POD for Git::Raw::Tree::Entry, the id() method is not explained correctly. The correct description is given in libgit2 API:
Get the id of the object pointed by the entry

git_index_add_frombuffer() in libgit2 updates the entry with the blob ID. Please make the corresponding method in Git::Raw::Index return a Git::Raw::Index::Entry object.

Use case: after calling add_frombuffer(), I can compare the blob ID with the previous value, and immediately derive if the data file was changed.

Compilation fails on FreeBSD systems:

 xs/libgit2/include/git2/transport.h:15:21: error: libssh2.h: No such file or directory

libssh2 is installed and the check_lib check before was apparently successful. Problem is that 3rd party libraries are install to /usr/local on *BSD systems, and probably Makefile.PL does not address this.

Regards, Slaven

Hi,

libgit2 sources contain a file CHANGELOG.md which allows a reader to identify which version of libgit2 is used by Git-Raw. Unfortunately, this file is not present in Git-Raw/deps/libgit2. I suspect that you remove it from your convenience copy.

It would be really really nice to your packagers (and to security reviewers) if it would be easier to identify the version of libgit2 that is in use.

Greetings
Marc

Here's an example from an existing repo I have:

> git cat-file -p b2c63b31b59ef9f638b62b90ccccd370eedf64be
100644 blob e3def7f930f98b83d11654eaf4a10db19896f25e    .gitmodules
160000 commit b79b2fcd76dbab3a4eceae494384ed96f7b0cb42  build
160000 commit f3a5e961e95b9b3ba877aa4193f28ad0b1e39922  build:codesearch-gitlink-overlay
160000 commit 7be5101e9f344ea2b0b96f648d377c31199fe6fe  infra
160000 commit 41ebd3375422d4274e885410434c88864181b7a4  infra:codesearch-gitlink-overlay
160000 commit b324e0140b97c11b7fe580336c050d6e2afce169  src
160000 commit b740576619c47566a6ef124002d54fcdf4804c78  src:codesearch-gitlink-overlay
040000 tree 101e2616c4955fdd60a28c6a9cbbd9f709ce97b9    tools

While trying to recreate this using Git::Raw::Tree::Builder, I encountered an error since I can't lookup the submodule commits since they exist in another git repo. Looking in xs/Tree/Builder.xs (and the documentation), the insert function can only accept blobs or trees.

I can try to figure out how to modify xs/Tree/Builder.xs to be able to accept these submodule ids, but would need to know how exactly you would prefer that to be structured?

I could change the if/else statement in the PPCODE section to an if/else if (tree)/else where the else would just assume you pass in a raw SHA-1? Doesn't quite seem as elegant, but I don't see another way since any type of submodule lookup just won't work...

t/34-rebase.t fails on some of my smoker systems:

Invalid type for 'name', expected a string at t/34-rebase.t line 25# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 6.
t/34-rebase.t ............... 
Dubious, test returned 255 (wstat 65280, 0xff00)
All 6 subtests passed 

Sometimes it's a variation:

Invalid type for 'email', expected a string ...

I cannot recall this error when we first implement str_add().

In file included from /usr/lib/x86_64-linux-gnu/perl/5.28/CORE/perl.h:5310,
from Raw.xs:2:
./xs/Config.xs: In function ‘XS_Git__Raw__Config_str_add’:
./xs/Config.xs:166:15: warning: passing argument 2 of ‘Perl_sv_2mortal’ from incompatible pointer type [-Wincompatible-pointer-types]
sv_2mortal(av);
^~
/usr/lib/x86_64-linux-gnu/perl/5.28/CORE/embed.h:719:46: note: in definition of macro ‘sv_2mortal’
#define sv_2mortal(a)  Perl_sv_2mortal(aTHX_ a)
^
In file included from /usr/lib/x86_64-linux-gnu/perl/5.28/CORE/perl.h:5271,
from Raw.xs:2:
/usr/lib/x86_64-linux-gnu/perl/5.28/CORE/proto.h:3140:19: note: expected ‘SV * const’ {aka ‘struct sv * const’} but argument is of type ‘AV *’ {aka ‘struct av *’}
PERL_CALLCONV SV* Perl_sv_2mortal(pTHX_ SV *const sv);
^~~~~~~~~~~~~~~```

With 0.66 and 0.67 I see the following test failure with self-compiled perls (5.12.3, 5.24.0, 5.25.8):

#   Failed test at t/01-repo.t line 79.
#          got: '0'
#     expected: '1'
# Looks like you failed 1 test of 125.
t/01-repo.t ................. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/125 subtests 

Looking at the failing test line the reason is clear:

is $caps{ignore_case}, 1 if ($^O eq 'darwin' || $^O eq 'MSWin32');

I configured my filesystem to be case-sensitive.

The current API only supports retrieving the status of a single file i.e. $repo->status($file). It also assumes that you know what the filename is, which does not quite work that well for untracked files. Rename detection also seems to work with libgit2 these days, so it will be a good idea to update the API anyway..

Pygit2 implements this as two methods, status_file and status. It might be a good idea to follow a similar approach?

What $subject says. While this is good for 90% of use cases, there are instances when you don't want to update HEAD.

These methods of Git::Raw::Tree::Builder return values, and the documentation does not reflect that:

insert returns an Git::Raw::Tree::Entry

write returns a Git::Raw::Tree

Hello all together,

small but big bug (or i'm an idiot) in Repository.pm.

error:

The requested type does not match the type in the ODB at /opt/perl5.14/lib/site_perl/5.14.2/i686-linux-thread-multi/Git/Raw/Repository.pm line 249

context:
...
245: my $tags;
246:
247: Git::Raw::Tag -> foreach($self, sub {
248: push @$tags, shift; 0
249: }); <------
250:
251: return $tags;
252: }
253:
...
code stack: /opt/perl5.14/lib/site_perl/5.14.2/i686-linux-thread-multi/Git/Raw/Repository.pm:249

lg levthan

Git-Raw-0.30-TRIAL (perl 5.14.2 / cygwin)

You can reproduce it by this modified test:

--- Git-Raw-0.30.orig/t/04-walker.t     2014-01-26 14:39:13.000000000 +0100
+++ Git-Raw-0.30/t/04-walker.t  2014-01-30 10:35:42.127447800 +0100
@@ -43,4 +43,10 @@
 is $walk -> next -> message, "initial commit\n";
 is $walk -> next, undef;

+$walk -> push_head;
+my $commit = $walk -> next;
+isnt $commit, undef;
+isnt $commit -> tree, undef;
+isnt $commit -> parents, undef;
+
 done_testing;

The method is documented as:

lookup( $name )

Retrieve the reference with name $name.

It doesn't mention anything about the repository argument.

lookup( $name, $repository )

Retrieve the reference with name $name in $repository.

I have merge.conflictstyle set to diff3 globally, and this causes t/15-merge.t to fail.

hi again

in POD, Git::Raw::Repository->merge() is described to return a hash. In XS, it returns nothing.

The POD for Git::Raw::Remote lists clear_refspecs(), but this function is not implemented in XS.

Compilation of 0.66 fails with bleadperl (e.g. 5.25.8):

cc -c  -I. -Ideps/libgit2 -Ideps/libgit2/src -Ideps/libgit2/include -Ideps/libgit2/deps/http-parser -Ideps/libgit2/deps/zlib -I/usr/local/include  -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_FORTIFY_SOURCE=2  -Wall -Wno-unused-variable -O2 -pipe    -DVERSION=\"0.66\"  -DXS_VERSION=\"0.66\" -DPIC -fPIC "-I/usr/perl5.25.8p/lib/5.25.8/amd64-freebsd/CORE"  -DGIT_SSH -DGIT_OPENSSL -DGIT_CURL -DNO_VIZ -DSTDC -DNO_GZIP -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DGIT_USE_STAT_MTIM -DGIT_USE_STAT_MTIM_NSEC -DGIT_USE_NEC Raw.c -o Raw.o
Raw.xs:230:48: error: no member named 'op_sibling' in 'struct op'
                for (kid = cUNOPo->op_first; kid; kid = kid->op_sibling) {
                                                        ~~~  ^
Raw.xs:255:52: error: no member named 'op_sibling' in 'struct cop'
        cop = git_closest_cop(aTHX_ PL_curcop, PL_curcop->op_sibling, PL_op, FALSE);
                                               ~~~~~~~~~  ^
2 errors generated.
*** Error code 1

The overloads in Blob, Commit, Error and Tree lack fallbacks. This can cause strange behavior. It means, for example, cmp will not use the eq method nor the "" method.