Given:

1. All tests (even Clone) initialize a Repository before they run a test
2. The tests that make use of Clone seem to be using a local file path
3. The limited number of examples available

I am not really sure if this is due to a misuse of the API, or a bug. In any case, the following used to work before not too long ago with git2go/v31 and backing crypto / transport dependencies:

func TestRemoteClone(t *testing.T) {
	t.Parallel()
	path, err := ioutil.TempDir("", "git2go")
	if err != nil {
		t.Fatalf("Failed to init temp dir")
	}
	defer os.RemoveAll(path)
	remote, err := Clone("https://github.com/libgit2/libgit2", path, &CloneOptions{})
	if err != nil {
		t.Fatalf("Clone() = %v, want success", err)
	}
	defer remote.Free()
}

While attempting to update to git2go/v32 however, and trying to depend on less C libraries, this now returns a remote pointer not found error:

=== RUN   TestRemoteClone
=== PAUSE TestRemoteClone
=== CONT  TestRemoteClone
    remote_test.go:94: Clone() = remote pointer not found, want success
--- FAIL: TestRemoteClone (0.00s)

Following the breadcrumbs, it seems to end on https://github.com/libgit2/git2go/blob/main/clone.go#L43 returning -7 (which makes me wonder even more).

I'm still getting familiar with git2go and libgit2, but I did some digging and it seems git_clone() already does deallocate git_repository: https://github.com/libgit2/libgit2/blob/development/src/clone.c#L425. So, having this finalizer seems unnecessary: https://github.com/libgit2/git2go/blob/make-static/clone.go#L53

After upgrading from go1.3 to go1.4, I'd get a runtime crash most of the time. It crashes for various reasons (nil tree walker callback, invalid heap pointer...). Here is a scaled down version of the code that demonstrates the problem (runtime crashes most of the time). Run this code with an argument pointing at a git repository like git2go.

package main

import (
    "fmt"
    "github.com/libgit2/git2go"
    "os"
    "strings"
)

type MyRepo struct {
    *git.Repository
}

func (repository *MyRepo) foo(path string, treeEntry *git.TreeEntry) int {
    if git.ObjectBlob != treeEntry.Type {
        return 0 // continue
    }

    if !strings.HasSuffix(treeEntry.Name, ".go") {
        return 0 // continue
    }

    blob, err := repository.Repository.LookupBlob(treeEntry.Id)
    defer blob.Free()
    if err != nil {
        panic(err)
    }

    if blob.Size() > 10000 {
        return 0 // continue
    }

    contents := blob.Contents()
    if contents == nil {
        panic("nil contents")
    }
    fmt.Printf("%q", path, treeEntry.Name, string(contents))
    fmt.Println()

    return 0 // continue
}

func main() {
    filename := os.Args[1]

    repository, err := git.OpenRepository(filename)
    if err != nil {
        panic(err)
    }
    defer repository.Free()

    myRepo := MyRepo{repository}

    revWalk, err := repository.Walk()
    if err != nil {
        panic(err)
    }
    defer revWalk.Free()

    // Start out at the head
    err = revWalk.PushHead()
    if err != nil {
        panic(err)
    }

    err = revWalk.Iterate(func(commit *git.Commit) bool {
        defer commit.Free()

        tree, err := commit.Tree()
        if err != nil {
            panic(err)
        }
        defer tree.Free()

        err = tree.Walk(myRepo.foo)
        if err != nil {
            panic(err)
        }

        return true
    })

    if err != nil {
        panic(err)
    }
}

Some errors that come from the above code:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x40f4299]

goroutine 1 [running]:
github.com/libgit2/git2go.CallbackGitTreeWalk(0x438a520, 0x51008e0, 0xc208071e40, 0x0)
    /Users/maleticm/.gvm/pkgsets/go1.4/jack/src/github.com/libgit2/git2go/tree.go:99 +0x79
github.com/libgit2/git2go._Cfunc__go_git_treewalk(0x5100850, 0x0, 0xc208069e40, 0x0)
    /Users/maleticm/.gvm/pkgsets/go1.4/jack/src/github.com/libgit2/git2go/:402 +0x43
github.com/libgit2/git2go.Tree.Walk(0x5100850, 0xc20802c018, 0x5100850, 0xc208069e80, 0x0, 0x0)

runtime: garbage collector found invalid heap pointer *(0xc208069cd0+0x10)=0xc208083e40 span=0xc20807e000-0xc208083800-0xc208084000 state=0
fatal error: invalid heap pointer

runtime stack:
runtime.throw(0x437df83)
    /Users/maleticm/.gvm/gos/go1.4/src/runtime/panic.go:491 +0xad fp=0x7fff5fbfea18 sp=0x7fff5fbfe9e8
scanblock(0xc208069cd0, 0x20, 0x42c12e4)
    /Users/maleticm/.gvm/gos/go1.4/src/runtime/mgc0.c:378 +0x551 fp=0x7fff5fbfeb58 sp=0x7fff5fbfea18
scanframe(0x7fff5fbfec60, 0x0, 0x1)
    /Users/maleticm/.gvm/gos/go1.4/src/runtime/mgc0.c:740 +0x1c2 fp=0x7fff5fbfebc8 sp=0x7fff5fbfeb58

unexpected fault address 0xb01dfacedebac1e
fatal error: fault
[signal 0xb code=0x1 addr=0xb01dfacedebac1e pc=0x40f4299]

goroutine 1 [running, locked to thread]:
runtime.gothrow(0x426ec90, 0x5)
    /Users/maleticm/.gvm/gos/go1.4/src/runtime/panic.go:503 +0x8e fp=0xc208069c40 sp=0xc208069c28
runtime.sigpanic()
    /Users/maleticm/.gvm/gos/go1.4/src/runtime/sigpanic_unix.go:29 +0x261 fp=0xc208069c90 sp=0xc208069c40
github.com/libgit2/git2go.CallbackGitTreeWalk(0x438a520, 0x5009680, 0xc208073e40, 0x0)

commit 98793509039cc80b774c527d9e5a7b5d70e3b6c4
Author: Shawn Landden <[email protected]>
Date:   Sat Mar 14 15:42:25 2015 -0700

    GIT_CHECKOUT_SAFE_CREATE has been removed in libgit2

    Signed-off-by: Shawn Landden <[email protected]>

diff --git a/checkout.go b/checkout.go
index 6eb6098..9456168 100644
--- a/checkout.go
+++ b/checkout.go
@@ -15,7 +15,6 @@ type CheckoutStrategy uint
 const (
        CheckoutNone                      CheckoutStrategy = C.GIT_CHECKOUT_NONE                         // Dry run, no actual updates
        CheckoutSafe                      CheckoutStrategy = C.GIT_CHECKOUT_SAFE                         // Allow safe updates that cannot overwrite uncommitted data
-       CheckoutSafeCreate                CheckoutStrategy = C.GIT_CHECKOUT_SAFE_CREATE                  // Allow safe updates plus creation of missing files
        CheckoutForce                     CheckoutStrategy = C.GIT_CHECKOUT_FORCE                        // Allow all updates to force working directory to look like index
        CheckoutAllowConflicts            CheckoutStrategy = C.GIT_CHECKOUT_ALLOW_CONFLICTS              // Allow checkout to make safe updates even if conflicts are found
        CheckoutRemoveUntracked           CheckoutStrategy = C.GIT_CHECKOUT_REMOVE_UNTRACKED             // Remove untracked files not in index (that are not ignored)

Right now, this package requires custom manual steps for its installation:

Run go get -d github.com/libgit2/git2go to download the code and go to your $GOPATH/src/github.com/libgit2/git2go dir. From there, we need to build the C code and put it into the resulting go binary.

git submodule update --init # get libgit2
make install

will compile libgit2 and run go install such that it's statically linked to the git2go package.

This is inconvenient, it makes it harder to get than other Go packages (which are just go get). Worst of all, this means that any other Go package that imports this one, even if the upstream package is completely go gettable, will no longer be 1 command to install.

I think it may be possible for you to change that, and thus improve the experience of anyone using this packages, and make it easy for others to import it and no incur the cost of manual dependency installation steps.

The way you can do that would be similar to how we did it with glfw3 package (currently on a branch, to be merged into master once GLFW 3.1 is released), which is a Go binding for a C library. It was discovered by @slimsag and you can see the discussion in the following issue and PR:

https://github.com/go-gl/glfw3/issues/82 https://github.com/go-gl/glfw3/pull/83

The general idea is that you vendor the C library source in a subfolder (potentially as a git submodule) and use cgo directives to link to it. Basically, everything you're doing now, except without needing the Makefile and scripts.

The main consideration is that you will need to replace the function of CMake with multiple .go files with build tags (which may require some work and maintenance), which is what we've done in glfw3:

Less configurable? Unable to modify CMAKE parameters?

Actually -- We can make build tags for any CMAKE configurable feature that we want (e.g. tell people to compile their application with go install -tags "wayland" my/pkg and a wayland client will be built instead of an X11 one, you can see how I did this here: https://github.com/go-gl/glfw3/blob/devel_glfw3.1/build.go)

But the end result is a go gettable package that is much easier for users. Just imagine:

To install git2go, run go get -u github.com/libgit2/git2go. Done.

What do you think? If this is something you're amendable to, I can assist with questions/answers about the approach and potentially try to make a PR.

This also adds a submodule so we know which version of libgit2 we're building against. Statically linking libgit2 gets us closer to the way Go does things.

We do however still link dynamically with libgit2's dependencies, namely openssl and libssh2 if available.

Add function in repository.go to initialize a repository with a custom ODB backend.

I am unsure how to write tests for this, as the test environment would require a custom ODB backend.

In the meantime, you can install my Kyoto Tycoon backend from https://github.com/anulman/libgit2/tree/kyoto (set -DGIT_ODB_KYOTO=ON before building) and use the following routine to test:

package main

/*
#cgo pkg-config: libgit2
#include <git2.h>
#include <git2/backends/kyotoTycoon/odb_kyoto.h>
*/
import "C"
import (
    "errors"
    "fmt"
    "github.com/libgit2/git2go"
    "os"
    "unsafe"
)

const kyotoPath string = "http://localhost:1978/"

func main() {
    // define initStrategy abstract function for custom backend init
    initStrategy := func(repo **C.git_repository, odb **C.git_odb) (ret int) {
        // convert path for use in c
        cpath := C.CString(kyotoPath)
        defer C.free(unsafe.Pointer(cpath))

        // handoff to c, convert C.int to int for error check
        cret := C.git_odb_backend_wrap_kyoto(repo, odb, cpath)
        ret = int(cret)

        return
    }

    _, odb, err := git.InitRepositoryWCustomOdbBackend(initStrategy)
    defer odb.Free()

    if err != nil {
        fmt.Println(err)
        return
    }

    if len(os.Args) < 3 {
        err = errors.New("call with (w)rite/(r)ead + data/oid")
        fmt.Println(err)
        return
    }

    if os.Args[1] == "write" || os.Args[1] == "w" {
        oid, err := odb.Write([]byte(os.Args[2]), git.ObjectBlob)
        if err == nil {
            fmt.Println("oid:", oid)
            return
        }
    } else if os.Args[1] == "read" || os.Args[1] == "r" {
        oid, err := git.NewOidFromString(os.Args[2])
        if err == nil {
            obj, err := odb.Read(oid)
            if err == nil {
                fmt.Println("obj data:", string(obj.Data()))
                return
            }
        }
    } else {
        fmt.Println("unrecognized command:", os.Args[1])
    }

    if err != nil {
        fmt.Println(err)
        return
    }
}

run with:

go run [file] w [string]
go run [file] r [returned oid]

During compilation git2go performs the following libgit2 version check:

https://github.com/libgit2/git2go/blob/ad3ec3664d54779c4c2e49e41f85e886fbff343c/git_system_dynamic.go#L10-L12

Suppose I want to install a go software which uses git2go through go get on both Ubuntu 20.04 and Arch Linux I would run into the following problem: These Linux distributions ship different versions of libgit2. Since the version check performed by git2go is very strict (requiring an exact match of both minor and major version) the aforementioned go software would only compile with one specific version of libgit2, according to the version suffix I used for the git2go import.

IMHO it would be desirable if the git2go version check would be less strict. If I am informed correctly, libgit2 uses semantic versioning. As such, the API should not change in backwards incompatible ways without a major version bump. For instance, github.com/libgit2/git2go/v30 (which currently requires libgit2 1.0.0) should IMHO compile with any libgit2 version where LIBGIT2_VER_MAJOR == 1 and LIBGIT2_VER_MINOR >= 0 (e.g. should compile fine with both libgit2 1.1.0 and libgit2 1.0.0).

This pull request fixes issues with Go callbacks that are handed over to C functions. As of Go 1.4 it is not possible to hand over Go pointers into C code as the garbage collector is allowed to copy around the stack, causing pointers to become invalid (see golang/go#8310 and golang/go#10303 for more information).

@carlosmn proposed an interface HandleList for pointer indirection which provides a global map of data that is to be tracked. Instead of handing in pointers we now instead hand over an index that points to the corresponding entry in this map.

This PR adds the HandleList implemented by @carlosmn, fixes some issues with it and adjusts code that hands over Go pointers into C code to use handles instead. Still missing is the remote.go code, as I am running into some error there ('runtime: garbage collector found invalid heap pointer *(0xc208063cd0+0x18)=0x1 s=nil') that I've not been able to fix.

This PR also fixes #163.

When I install libgit2 using homebrew and then try to go build git2go I get the following error:

# github.com/libgit2/git2go
37: error: use of undeclared identifier 'git_remote_create_cb'; did you mean 'git_remote_create'?

Hi team!

I am creating a funny library with git2go/libgit2: gitql. But I think that set $LD_LIBRARY_PATH everytime before run it is a bad idea :confused: I would like know if there is other way because set that variable globally seems bad too

Thanks! And congrats for this bind! :smile:

The golang.org/x/crypto/openpgp library has been deprecated for over a year now (see https://golang.org/issue/44226, and the deprecation notice in the package documentation). The library is unmaintained and has a number of API and usability issues. ProtonMail maintains a community fork which is actively maintained, and for most cases is a drop-in replacement.

This change switches usages of golang.org/x/crypto/openpgp/... with github.com/ProtonMail/go-crypto/openpgp/..., the only other code changes are adding a nil packet.Config to a openpgp.CheckArmoredDetachedSignature call.

(This change is part of a wider effort by the Go Security team to remove usages of golang.org/x/crypto/openpgp from the Go ecosystem.)

In this list:

https://github.com/libgit2/git2go#which-go-version-to-use

One should use libgit2 v1.5 with git2go v34

The text implies libgit2 v1.2 with git2go v34

"You can import them in your project with the version's major number as a suffix. For example, if you have libgit2 v1.2 installed, you'd import git2go v34 with:"

I updated the two relevant sentences in this PR https://github.com/libgit2/git2go/pull/939

There are many Pull Requests open, but none of them reviewed or even commented except old ones. I see that there was a new release few days ago, but it could include these improvements from me #926 and for example from @clns with #913. Now these features will postponed again maybe forever. Can someone review this backlog or this project is archived and don't accept new features?

cc @lhchavez @carlosmn