3f9fb4ff68
This change is a preparation for another change that makes all callback
types return a Go error instead of an error code / an integer. That is
going to make make things a lot more idiomatic.
The reason this change is split is threefold:
a) This change is mostly mechanical and should contain no semantic
changes.
b) This change is backwards-compatible (in the Go API compatibility
sense of the word), and thus can be backported to all other releases.
c) It makes the other change a bit smaller and more focused on just one
thing.
Concretely, this change makes all callbacks populate a Go error when
they fail. If the callback is invoked from the same stack as the
function to which it was passed (e.g. for `Tree.Walk`), it will preserve
the error object directly into a struct that also holds the callback
function. Otherwise if the callback is pased to one func and will be
invoked when run from another one (e.g. for `Repository.InitRebase`),
the error string is saved into the libgit2 thread-local storage and then
re-created as a `GitError`.
(cherry picked from commit
|
||
---|---|---|
.github/workflows | ||
script | ||
vendor | ||
.gitignore | ||
.gitmodules | ||
.travis.yml | ||
LICENSE | ||
Makefile | ||
README.md | ||
blame.go | ||
blame_test.go | ||
blob.go | ||
blob_test.go | ||
branch.go | ||
branch_test.go | ||
checkout.go | ||
cherrypick.go | ||
cherrypick_test.go | ||
clone.go | ||
clone_test.go | ||
commit.go | ||
config.go | ||
config_test.go | ||
credentials.go | ||
delta_string.go | ||
deprecated.go | ||
describe.go | ||
describe_test.go | ||
diff.go | ||
diff_test.go | ||
difflinetype_string.go | ||
errorclass_string.go | ||
errorcode_string.go | ||
features.go | ||
git.go | ||
git_bundled_static.go | ||
git_system_dynamic.go | ||
git_system_static.go | ||
git_test.go | ||
go.mod | ||
go.sum | ||
graph.go | ||
handles.go | ||
ignore.go | ||
index.go | ||
index_test.go | ||
indexer.go | ||
indexer_test.go | ||
mempack.go | ||
mempack_test.go | ||
merge.go | ||
merge_test.go | ||
message.go | ||
message_test.go | ||
note.go | ||
note_test.go | ||
object.go | ||
object_test.go | ||
odb.go | ||
odb_test.go | ||
packbuilder.go | ||
patch.go | ||
patch_test.go | ||
push_test.go | ||
rebase.go | ||
rebase_test.go | ||
refdb.go | ||
reference.go | ||
reference_test.go | ||
remote.go | ||
remote_test.go | ||
repository.go | ||
repository_test.go | ||
reset.go | ||
reset_test.go | ||
revert.go | ||
revert_test.go | ||
revparse.go | ||
revparse_test.go | ||
settings.go | ||
settings_test.go | ||
signature.go | ||
stash.go | ||
stash_test.go | ||
status.go | ||
status_test.go | ||
submodule.go | ||
submodule_test.go | ||
tag.go | ||
tag_test.go | ||
tree.go | ||
tree_test.go | ||
walk.go | ||
wrapper.c |
README.md
git2go
Go bindings for libgit2.
Which Go version to use
Due to the fact that Go 1.11 module versions have semantic meaning and don't necessarily align with libgit2's release schedule, please consult the following table for a mapping between libgit2 and git2go module versions:
libgit2 | git2go |
---|---|
master | (will be v31) |
1.0 | v30 |
0.99 | v29 |
0.28 | v28 |
0.27 | v27 |
You can import them in your project with the version's major number as a suffix. For example, if you have libgit2 v1.0 installed, you'd import git2go v30 with
go get github.com/libgit2/git2go/v30
import "github.com/libgit2/git2go/v30"
which will ensure there are no sudden changes to the API.
The master
branch follows the tip of libgit2 itself (with some lag) and as such has no guarantees on the stability of libgit2's API. Thus this only supports statically linking against libgit2.
Which branch to send Pull requests to
If there's something version-specific that you'd want to contribute to, you can send them to the release-${MAJOR}.${MINOR}
branches, which follow libgit2's releases.
Installing
This project wraps the functionality provided by libgit2. It thus needs it in order to perform the work.
This project wraps the functionality provided by libgit2. If you're using a versioned branch, install it to your system via your system's package manager and then install git2go.
Versioned branch, dynamic linking
When linking dynamically against a released version of libgit2, install it via your system's package manager. CGo will take care of finding its pkg-config file and set up the linking. Import via Go modules, e.g. to work against libgit2 v1.0
import "github.com/libgit2/git2go/v30"
Versioned branch, static linking
Follow the instructions for Versioned branch, dynamic linking, but pass the -tags static,system_libgit2
flag to all go
commands that build any binaries. For instance:
go build -tags static,system_libgit2 github.com/my/project/...
go test -tags static,system_libgit2 github.com/my/project/...
go install -tags static,system_libgit2 github.com/my/project/...
Master branch, or vendored static linking
If using master
or building a branch with the vendored libgit2 statically, we need to build libgit2 first. In order to build it, you need cmake
, pkg-config
and a C compiler. You will also need the development packages for OpenSSL (outside of Windows or macOS) and LibSSH2 installed if you want libgit2 to support HTTPS and SSH respectively. Note that even if libgit2 is included in the resulting binary, its dependencies will not be.
Run go get -d github.com/libgit2/git2go
to download the code and go to your $GOPATH/src/github.com/libgit2/git2go
directory. 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-static
will compile libgit2, link it into git2go and install it. The master
branch is set up to follow the specific libgit2 version that is vendored, so trying dynamic linking may or may not work depending on the exact versions involved.
In order to let Go pass the correct flags to pkg-config
, -tags static
needs to be passed to all go
commands that build any binaries. For instance:
go build -tags static github.com/my/project/...
go test -tags static github.com/my/project/...
go install -tags static github.com/my/project/...
One thing to take into account is that since Go expects the pkg-config
file to be within the same directory where make install-static
was called, so the go.mod
file may need to have a replace
directive so that the correct setup is achieved. So if git2go
is checked out at $GOPATH/src/github.com/libgit2/git2go
and your project at $GOPATH/src/github.com/my/project
, the go.mod
file of github.com/my/project
might need to have a line like
replace github.com/libgit2/git2go/v30 ../../libgit2/git2go
Parallelism and network operations
libgit2 may use OpenSSL and LibSSH2 for performing encrypted network connections. For now, git2go asks libgit2 to set locking for OpenSSL. This makes HTTPS connections thread-safe, but it is fragile and will likely stop doing it soon. This may also make SSH connections thread-safe if your copy of libssh2 is linked against OpenSSL. Check libgit2's THREADSAFE.md
for more information.
Running the tests
For the stable version, go test
will work as usual. For the master
branch, similarly to installing, running the tests requires building a local libgit2 library, so the Makefile provides a wrapper that makes sure it's built
make test-static
Alternatively, you can build the library manually first and then run the tests
make install-static
go test -v -tags static ./...
License
M to the I to the T. See the LICENSE file if you've never seen an MIT license before.
Authors
- Carlos Martín (@carlosmn)
- Vicent Martí (@vmg)