libgit2 / libgit2

A cross-platform, linkable library implementation of Git that you can use in your application.

libgit2 - the Git linkable library

Build Status
main branch CI builds
v1.8 branch CI builds
v1.7 branch CI builds
Nightly builds

libgit2 is a portable, pure C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Language bindings like Rugged (Ruby), LibGit2Sharp (.NET), pygit2 (Python) and NodeGit (Node) allow you to build Git tooling in your favorite language.

libgit2 is used to power Git GUI clients like GitKraken and GitButler and on Git hosting providers like GitHub, GitLab and Azure DevOps. We perform the merge every time you click "merge pull request".

libgit2 is licensed under a very permissive license (GPLv2 with a special Linking Exception). This means that you can link against the library with any kind of software without making that software fall under the GPL. Changes to libgit2 would still be covered under its GPL license. Additionally, the example code has been released to the public domain (see the separate license for more information).

Table of Contents

• Using libgit2
• Quick Start
• Getting Help
• What It Can Do
• Optional dependencies
• Initialization
• Threading
• Conventions
• Building libgit2 - Using CMake
  • Building
  • Installation
  • Advanced Usage
  • Compiler and linker options
  • MacOS X
  • Android
  • MinGW
• Language Bindings
• How Can I Contribute?
• License

Using libgit2

Most of these instructions assume that you're writing an application in C and want to use libgit2 directly. If you're not using C, and you're writing in a different language or platform like .NET, Node.js, or Ruby, then there is probably a "language binding" that you can use to take care of the messy tasks of calling into native code.

But if you do want to use libgit2 directly - because you're building an application in C - then you may be able use an existing binary. There are packages for the vcpkg and conan package managers. And libgit2 is available in Homebrew and most Linux distributions.

However, these versions may be outdated and we recommend using the latest version if possible. Thankfully libgit2 is not hard to compile.

Quick Start

Prerequisites for building libgit2:

1. CMake, and is recommended to be installed into your PATH.
2. Python is used by our test framework, and should be installed into your PATH.
3. C compiler: libgit2 is C90 and should compile on most compilers.
   • Windows: Visual Studio is recommended
   • Mac: Xcode is recommended
   • Unix: gcc or clang is recommended.

Build

1. Create a build directory beneath the libgit2 source directory, and change into it: mkdir build && cd build
2. Create the cmake build environment: cmake ..
3. Build libgit2: cmake --build .

Trouble with these steps? Read our troubleshooting guide. More detailed build guidance is available below.

Getting Help

Chat with us

• via IRC: join #libgit2 on libera.
• via Slack: visit slack.libgit2.org to sign up, then join us in #libgit2

Getting Help

If you have questions about the library, please be sure to check out the API documentation. If you still have questions, reach out to us on Slack or post a question on StackOverflow (with the libgit2 tag).

Reporting Bugs

Please open a GitHub Issue and include as much information as possible. If possible, provide sample code that illustrates the problem you're seeing. If you're seeing a bug only on a specific repository, please provide a link to it if possible.

We ask that you not open a GitHub Issue for help, only for bug reports.

Reporting Security Issues

Please have a look at SECURITY.md.

What It Can Do

libgit2 provides you with the ability to manage Git repositories in the programming language of your choice. It's used in production to power many applications including GitHub.com, Plastic SCM and Azure DevOps.

It does not aim to replace the git tool or its user-facing commands. Some APIs resemble the plumbing commands as those align closely with the concepts of the Git system, but most commands a user would type are out of scope for this library to implement directly.

The library provides:

• SHA conversions, formatting and shortening
• abstracted ODB backend system
• commit, tag, tree and blob parsing, editing, and write-back
• tree traversal
• revision walking
• index file (staging area) manipulation
• reference management (including packed references)
• config file management
• high level repository management
• thread safety and reentrancy
• descriptive and detailed error messages
• ...and more (over 175 different API calls)

As libgit2 is purely a consumer of the Git system, we have to adjust to changes made upstream. This has two major consequences:

• Some changes may require us to change provided interfaces. While we try to implement functions in a generic way so that no future changes are required, we cannot promise a completely stable API.
• As we have to keep up with changes in behavior made upstream, we may lag behind in some areas. We usually to document these incompatibilities in our issue tracker with the label "git change".

Optional dependencies

While the library provides git functionality without the need for dependencies, it can make use of a few libraries to add to it:

• pthreads (non-Windows) to enable threadsafe access as well as multi-threaded pack generation
• OpenSSL (non-Windows) to talk over HTTPS and provide the SHA-1 functions
• LibSSH2 to enable the SSH transport
• iconv (OSX) to handle the HFS+ path encoding peculiarities

Initialization

The library needs to keep track of some global state. Call

git_libgit2_init();

before calling any other libgit2 functions. You can call this function many times. A matching number of calls to

git_libgit2_shutdown();

will free the resources. Note that if you have worker threads, you should call git_libgit2_shutdown after those threads have exited. If you require assistance coordinating this, simply have the worker threads call git_libgit2_init at startup and git_libgit2_shutdown at shutdown.

Threading

See threading for information

Conventions

See conventions for an overview of the external and internal API/coding conventions we use.

Building libgit2 - Using CMake

Building

libgit2 builds cleanly on most platforms without any external dependencies. Under Unix-like systems, like Linux, *BSD and Mac OS X, libgit2 expects pthreads to be available; they should be installed by default on all systems. Under Windows, libgit2 uses the native Windows API for threading.

The libgit2 library is built using CMake (version 2.8 or newer) on all platforms.

On most systems you can build the library using the following commands

$ mkdir build && cd build
$ cmake ..
$ cmake --build .

Alternatively you can point the CMake GUI tool to the CMakeLists.txt file and generate platform specific build project or IDE workspace.

If you're not familiar with CMake, a more detailed explanation may be helpful.

Running Tests

Once built, you can run the tests from the build directory with the command

$ ctest -V

Alternatively you can run the test suite directly using,

$ ./libgit2_tests

Invoking the test suite directly is useful because it allows you to execute individual tests, or groups of tests using the -s flag. For example, to run the index tests:

$ ./libgit2_tests -sindex

To run a single test named index::racy::diff, which corresponds to the test function test_index_racy__diff:

$ ./libgit2_tests -sindex::racy::diff

The test suite will print a . for every passing test, and an F for any failing test. An S indicates that a test was skipped because it is not applicable to your platform or is particularly expensive.

Note: There should be no failing tests when you build an unmodified source tree from a release, or from the main branch. Please contact us or open an issue if you see test failures.

Installation

To install the library you can specify the install prefix by setting:

$ cmake .. -DCMAKE_INSTALL_PREFIX=/install/prefix
$ cmake --build . --target install

Advanced Usage

For more advanced use or questions about CMake please read https://cmake.org/Wiki/CMake_FAQ.

The following CMake variables are declared:

• CMAKE_INSTALL_BINDIR: Where to install binaries to.
• CMAKE_INSTALL_LIBDIR: Where to install libraries to.
• CMAKE_INSTALL_INCLUDEDIR: Where to install headers to.
• BUILD_SHARED_LIBS: Build libgit2 as a Shared Library (defaults to ON)
• BUILD_TESTS: Build the unit and integration test suites (defaults to ON)
• USE_THREADS: Build libgit2 with threading support (defaults to ON)

To list all build options and their current value, you can do the following:

# Create and set up a build directory
$ mkdir build
$ cmake ..
# List all build options and their values
$ cmake -L

Compiler and linker options

CMake lets you specify a few variables to control the behavior of the compiler and linker. These flags are rarely used but can be useful for 64-bit to 32-bit cross-compilation.

• CMAKE_C_FLAGS: Set your own compiler flags
• CMAKE_FIND_ROOT_PATH: Override the search path for libraries
• ZLIB_LIBRARY, OPENSSL_SSL_LIBRARY AND OPENSSL_CRYPTO_LIBRARY: Tell CMake where to find those specific libraries
• LINK_WITH_STATIC_LIBRARIES: Link only with static versions of system libraries

MacOS X

If you want to build a universal binary for Mac OS X, CMake sets it all up for you if you use -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" when configuring.

Android

Extract toolchain from NDK using, make-standalone-toolchain.sh script. Optionally, crosscompile and install OpenSSL inside of it. Then create CMake toolchain file that configures paths to your crosscompiler (substitute {PATH} with full path to the toolchain):

SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION Android)

SET(CMAKE_C_COMPILER   {PATH}/bin/arm-linux-androideabi-gcc)
SET(CMAKE_CXX_COMPILER {PATH}/bin/arm-linux-androideabi-g++)
SET(CMAKE_FIND_ROOT_PATH {PATH}/sysroot/)

SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Add -DCMAKE_TOOLCHAIN_FILE={pathToToolchainFile} to cmake command when configuring.

MinGW

If you want to build the library in MinGW environment with SSH support enabled, you may need to pass -DCMAKE_LIBRARY_PATH="${MINGW_PREFIX}/${MINGW_CHOST}/lib/" flag to CMake when configuring. This is because CMake cannot find the Win32 libraries in MinGW folders by default and you might see an error message stating that CMake could not resolve ws2_32 library during configuration.

Another option would be to install msys2-w32api-runtime package before configuring. This package installs the Win32 libraries into /usr/lib folder which is by default recognized as the library path by CMake. Please note though that this package is meant for MSYS subsystem which is different from MinGW.

Language Bindings

Here are the bindings to libgit2 that are currently available:

• C++
  • libqgit2, Qt bindings https://projects.kde.org/projects/playground/libs/libqgit2/repository/
• Chicken Scheme
  • chicken-git https://wiki.call-cc.org/egg/git
• D
  • dlibgit https://github.com/s-ludwig/dlibgit
• Delphi
  • GitForDelphi https://github.com/libgit2/GitForDelphi
  • libgit2-delphi https://github.com/todaysoftware/libgit2-delphi
• Erlang
  • Geef https://github.com/carlosmn/geef
• Go
  • git2go https://github.com/libgit2/git2go
• GObject
  • libgit2-glib https://wiki.gnome.org/Projects/Libgit2-glib
• Guile
  • Guile-Git https://gitlab.com/guile-git/guile-git
• Haskell
  • hgit2 https://github.com/jwiegley/gitlib
• Java
  • Jagged https://github.com/ethomson/jagged
  • Git24j https://github.com/git24j/git24j
• Javascript / WebAssembly ( browser and nodejs )
  • WASM-git https://github.com/petersalomonsen/wasm-git
• Julia
  • LibGit2.jl https://github.com/JuliaLang/julia/tree/master/stdlib/LibGit2
• Lua
  • luagit2 https://github.com/libgit2/luagit2
• .NET
  • libgit2sharp https://github.com/libgit2/libgit2sharp
• Node.js
  • nodegit https://github.com/nodegit/nodegit
• Objective-C
  • objective-git https://github.com/libgit2/objective-git
• OCaml
  • ocaml-libgit2 https://github.com/fxfactorial/ocaml-libgit2
• Parrot Virtual Machine
  • parrot-libgit2 https://github.com/letolabs/parrot-libgit2
• Perl
  • Git-Raw https://github.com/jacquesg/p5-Git-Raw
• Pharo Smalltalk
  • libgit2-pharo-bindings https://github.com/pharo-vcs/libgit2-pharo-bindings
• PHP
  • php-git2 https://github.com/RogerGee/php-git2
• Python
  • pygit2 https://github.com/libgit2/pygit2
• R
  • gert https://docs.ropensci.org/gert
  • git2r https://github.com/ropensci/git2r
• Ruby
  • Rugged https://github.com/libgit2/rugged
• Rust
  • git2-rs https://github.com/rust-lang/git2-rs
• Swift
  • SwiftGit2 https://github.com/SwiftGit2/SwiftGit2
• Tcl
  • lg2 https://github.com/apnadkarni/tcl-libgit2
• Vala
  • libgit2.vapi https://github.com/apmasell/vapis/blob/master/libgit2.vapi

If you start another language binding to libgit2, please let us know so we can add it to the list.

How Can I Contribute?

We welcome new contributors! We have a number of issues marked as "up for grabs" and "easy fix" that are good places to jump in and get started. There's much more detailed information in our list of outstanding projects.

Please be sure to check the contribution guidelines to understand our workflow, and the libgit2 coding conventions.

License

libgit2 is under GPL2 with linking exception. This means you can link to and use the library from any program, proprietary or open source; paid or gratis. However, if you modify libgit2 itself, you must distribute the source to your modified version of libgit2.

See the COPYING file for the full license text.

libgit2's Issues

git_repository_init on existing repositories

I imagine that repo_init_reinit should return GIT_SUCCESS while *repo_out still points to an undefined memory location.

static int repo_init_reinit(repo_init *results)
{
    /* TODO: reinit the repository */
    results->has_been_reinit = 1;
    return GIT_EINVALIDPATH; /* GIT_SUCCESS yields undefined behavior */
}

problem building (with cmake) on win32 - undefined reference to `deflateBound@8'

I'm unable to build on win32, I got :
CMakeFiles\git2.dir/objects.a(odb_loose.c.obj):odb_loose.c:(.text+0x411): undefined reference to `deflateBound@8'

Any idea?

cmake version 2.8.4
installed mingw with mingw-get-inst-20110211.exe
Installed the pthread library using instructions at https://github.com/roxlu/ofxHttpServer/blob/master/readme.txt

Log:
C:\Sources\libgit2\build>"c:\Program Files\CMake 2.8\bin\cmake.exe" -G "MinGW Makefiles" ..
-- The C compiler identification is GNU
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found ZLIB: C:/Program Files/GnuWin32/zlib/include (found version "1.2.5")
-- Could NOT find OpenSSL (missing: OPENSSL_LIBRARIES OPENSSL_INCLUDE_DIR)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Sources/libgit2/build

C:\Sources\libgit2\build>"c:\Program Files\CMake 2.8\bin\cmake.exe" --build .
Scanning dependencies of target git2
[ 1%] Building C object CMakeFiles/git2.dir/src/blob.c.obj
[ 2%] Building C object CMakeFiles/git2.dir/src/commit.c.obj
[ 4%] Building C object CMakeFiles/git2.dir/src/delta-apply.c.obj
[ 5%] Building C object CMakeFiles/git2.dir/src/errors.c.obj
[ 6%] Building C object CMakeFiles/git2.dir/src/filebuf.c.obj
[ 8%] Building C object CMakeFiles/git2.dir/src/fileops.c.obj
[ 9%] Building C object CMakeFiles/git2.dir/src/hash.c.obj
[ 11%] Building C object CMakeFiles/git2.dir/src/hashtable.c.obj
[ 12%] Building C object CMakeFiles/git2.dir/src/index.c.obj
[ 13%] Building C object CMakeFiles/git2.dir/src/object.c.obj
[ 15%] Building C object CMakeFiles/git2.dir/src/odb.c.obj
[ 16%] Building C object CMakeFiles/git2.dir/src/odb_loose.c.obj
[ 18%] Building C object CMakeFiles/git2.dir/src/odb_pack.c.obj
[ 19%] Building C object CMakeFiles/git2.dir/src/oid.c.obj
[ 20%] Building C object CMakeFiles/git2.dir/src/refs.c.obj
[ 22%] Building C object CMakeFiles/git2.dir/src/repository.c.obj
[ 23%] Building C object CMakeFiles/git2.dir/src/revwalk.c.obj
[ 25%] Building C object CMakeFiles/git2.dir/src/signature.c.obj
[ 26%] Building C object CMakeFiles/git2.dir/src/tag.c.obj
[ 27%] Building C object CMakeFiles/git2.dir/src/thread-utils.c.obj
[ 29%] Building C object CMakeFiles/git2.dir/src/tree.c.obj
[ 30%] Building C object CMakeFiles/git2.dir/src/util.c.obj
[ 31%] Building C object CMakeFiles/git2.dir/src/vector.c.obj
[ 33%] Building C object CMakeFiles/git2.dir/src/backends/sqlite.c.obj
[ 34%] Building C object CMakeFiles/git2.dir/src/win32/dir.c.obj
[ 36%] Building C object CMakeFiles/git2.dir/src/win32/fileops.c.obj
[ 37%] Building C object CMakeFiles/git2.dir/src/win32/map.c.obj
[ 38%] Building C object CMakeFiles/git2.dir/src/block-sha1/sha1.c.obj
Linking C shared library libgit2.dll
Creating library file: libgit2.dll.aWarning: resolving inflateInit@12 by linking to inflateInit
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _inflate@8 by linking to _inflate
Warning: resolving _inflateEnd@4 by linking to _inflateEnd
Warning: resolving deflateInit@16 by linking to deflateInit
Warning: resolving _deflate
@8 by linking to _deflate
Warning: resolving _deflateEnd@4 by linking to _deflateEnd
CMakeFiles\git2.dir/objects.a(odb_loose.c.obj):odb_loose.c:(.text+0x411): undefined reference to `deflateBound@8'
collect2: ld returned 1 exit status
mingw32-make.exe[2]: *** [libgit2.dll] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/git2.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2

git_tree_entry_byname fails apparently because of wrong sort order (in some cases)

git_tree_entry_byname returns NULL when it should not in some specific cases. Apparently
this is because the sort order of the tree is wrong, for instance with libgit2, within the 'include' folder, the entries are ordered this way:

git2.h
git2

While it should be the inverse, first the shortest string. And then bsearch fails (in function git_vector_bsearch2).

Below a test program that reproduces the problem. It prints "git2.h not found" while it should print "git2.h found".

#include <git2.h>
#include <stdio.h>

#define REPO "/home/jdavid/sandboxes/libgit2/.git"
#define TREE "693753506198e2d7832475975f6dc5ada3a502f3"
#define NAME "git2.h"

void main()
{
    int err;
    git_repository *repo;
    git_oid tree_id;
    git_object *tree;
    const git_tree_entry *entry;

    err = git_repository_open(&repo, REPO);
    err = git_oid_mkstr(&tree_id, TREE);
    err = git_object_lookup(&tree, repo, &tree_id, GIT_OBJ_TREE);
    entry = git_tree_entry_byname((git_tree*)tree, NAME);
    printf("%s %s\n", NAME, (entry == NULL ? "not found" : "found"));
}

bug Memory leak from git_commit object.

The 'parents' git_vector object in git_commit is not being freed in function git_commit__free().

Also I have created Lua bindings for LibGit2:
https://github.com/Neopallium/luagit2

lightweight tag support

Hi tanoku,

i sometimes use lightweight tag in my repositories.
i tried git_repository_lookup_ref API, but libgit2 can't detect lightweight tag.

lightweight tag same as branch. refer to a particular commit.
so libgit2 detect as GIT_OBJ_COMMIT.

I would be happy if you could fix this behavior someday.

Cheers,
Shuhei

packed_load() expects packed-refs to start with "# pack-refs with: peeled "

I have a repository here (created with git 1.7.0.4) that has a packed-refs with no comment header, just the hash -> ref map, and libgit2 refuses to parse it unless I comment out this snippet:

/* Does the header look like valid? */
if (git__prefixcmp((const char *)(buffer_start), GIT_PACKEDREFS_HEADER)) {
    error = GIT_EPACKEDREFSCORRUPTED;
    goto cleanup;
}

/* Let's skip the header */
buffer_start += strlen(GIT_PACKEDREFS_HEADER);

if (*buffer_start == '\r')
    buffer_start++;

if (*buffer_start != '\n')
    return GIT_EPACKEDREFSCORRUPTED;

buffer_start++;

segfault on revision walking

Under some specific conditions git_repository_free produces a segfault:

• start a revwalk, but do not exhaust it
• the sorting mode must include GIT_SORT_REVERSE

But it does not happen with all repositories. I reproduced the problem with the pygit2 repo:

$ git clone git://github.com/libgit2/pygit2.git /tmp/pygit2

Then run this code:

#include <git2.h>
void main () {
    git_repository *repo;
    git_oid oid;
    git_revwalk *walk;
    git_commit *head, *commit;
    const char *msg;
    const git_signature *author;
    /* repo */
    git_repository_open(&repo, "/tmp/pygit2/.git");
    /* revwalk */
    git_revwalk_new(&walk, repo);
    git_revwalk_sorting(walk, GIT_SORT_TOPOLOGICAL | GIT_SORT_REVERSE);
    /* push */
    git_oid_mkstr(&oid, "83a78dac5fe5702d4457577e2daa64fe795b551b");
    git_commit_lookup(&head, repo, &oid);
    git_revwalk_push(walk, head);
    /* run */
    git_revwalk_next(&commit, walk);
    /* free */
    git_revwalk_free(walk);
    git_repository_free(repo);
}

Most often I get just a segfault, but sometimes I get this:

*** glibc detected *** ./a.out: corrupted double-linked list: 0x0000000000f2c6e0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x72b56)[0x7f68e50f1b56]
/lib/libc.so.6(+0x72fcd)[0x7f68e50f1fcd]
/lib/libc.so.6(+0x74498)[0x7f68e50f3498]
/lib/libc.so.6(cfree+0x6c)[0x7f68e50f690c]
/usr/lib64/libgit2.so.0(git_hashtable_free+0x11)[0x7f68e53e30f1]
/usr/lib64/libgit2.so.0(git_repository_free+0x5e)[0x7f68e53e44de]
./a.out[0x400a2f]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f68e509dbbd]
./a.out[0x400899]
======= Memory map: ========

Status of Python bindings

http://libgit2.github.com/ says Python bindings are "Coming Soon..." I'm a developer on Dulwich, a pure-Python git implementation, and we're definitely interested in bindings. If they're already in progress, how can we help? If not, can we start them?

Redundant API

While exposing the API in .NET I came across git_commit_id and git_object_id which basically returns the same id. When took a look at the implementation:

const git_oid *git_commit_id(git_commit *c)
{
  return git_object_id((git_object *)c);
}

That seems kinda redundant to me, is there a good readon why this is done?

Stack overrun when commit_parse_buffer for big repository

commit_parse_buffer will call git_repository_lookup to get parent commit object.

git_repository_lookup will call commit_parse_buffer again to get parent commit object.

So call stack will be

git_repository_lookup
commit_parse_buffer
git_repository_lookup
commit_parse_buffer
git_repository_lookup
commit_parse_buffer

for big repository, commit number is large. so stack will overrun

Speed issues?

Hello,
I have tried to resolve the first commit resolving the HEAD reference.
Now when I do that with big repositories, the size of mono or git, it takes like forever (compared to the old git).
The revisionwalker is blazing fast, but the first lookup is soooo slow. Standard git does that much more faster (at least it seems to me that tig works kinda faster).

Maybe the developers have some comments about that?

git_treebuilder_insert: currupted objects in subtrees case

Hi, thank you for your developing this project.
This modification of trees test shows the way to corrupt tree object.
git show or git ls-tree on such trees gives:

error: sha1 mismatch 3653260ffaa380c9ab214988bcf4becf6e39c44a
fatal: not a tree object

but git cat-file:

git cat-file tree 3653260ffaa380c9ab214988bcf4becf6e39c44a
40000 new�����{�8@Nx�#Hp��OE�

Please correct me if something is wrong.

git_repository *repo;
git_treebuilder *builder;
git_tree *tree;
git_oid first_id, blob_id, result_id, subtree_id;

must_pass(open_temp_repo(&repo, REPOSITORY_FOLDER));

git_oid_mkstr(&first_id, first_tree);
git_oid_mkstr(&blob_id, blob_oid);

// create subtree with blob entry
must_pass(git_treebuilder_create(&builder,0));
must_pass(git_treebuilder_insert(NULL,builder,"new.txt",&blob_id,0100644));
must_pass(git_treebuilder_write(&subtree_id,repo,builder));
git_treebuilder_free(builder);
// create tree
must_pass(git_tree_lookup(&tree, repo, &first_id));
must_pass(git_treebuilder_create(&builder, tree));
must_pass(git_treebuilder_insert(NULL,builder,"new",&subtree_id,040000));
must_pass(git_treebuilder_write(&result_id,repo,builder));
must_be_true(0 == git_tree_lookup(&tree, repo, &result_id));

get commit using object id

How would one get the commit that last affected a tree or blob ? Preferably using the object id of the tree or blob.

ldconfig not running on *nix library install

I am on a debian squeeze box(Linux 2.6.32-5-686).

I had to run ldconfig manually to actually be able to use the shared library.
So, is that on propose, or is it needed to change wscript to call ldconfig?

Once built, git2.dll doesn't expose git_strerror() as an external entry point on Windows.

Behavior reproduced with both the Waf and CMake build scripts (MSVC 2010/Win 7).

Cheers,
Em.

Inconsistent types

GIT_EXTERN(unsigned int) git_tree_entry_attributes(git_tree_entry *entry);
GIT_EXTERN(void) git_tree_entry_set_attributes(git_tree_entry *entry, int attr);

Is it unsigned int or int? It may not be a big deal in C with no warnings, but my C# bindings explode on this difference.

segfault when using git_repository_open on non-existent repo

Assertion failed: (db), function git_odb_close, file ../../src/odb.c, line 213.

Program received signal SIGABRT, Aborted.
0x00007fff84301616 in __kill ()
(gdb) bt
#0 0x00007fff84301616 in __kill ()
#1 0x00007fff843a1cca in abort ()
#2 0x00007fff8438ec90 in __assert_rtn ()
#3 0x0000000100504419 in git_odb_close (db=<value temporarily unavailable, due to optimizations>) at ../../src/odb.c:213
#4 0x0000000100508006 in git_repository_free (repo=0x1004ce6b0) at ../../src/repository.c:313
#5 0x000000010050876d in git_repository_open (repo_out=0x7fff5fbff240, path=0x1003d6500 "t/random-non-existing-repo/") at ../../src/repository.c:290

(gdb) fr 4
#4 0x0000000100508006 in git_repository_free (repo=0x1004ce6b0) at ../../src/repository.c:313

313 git_odb_close(repo->db);
(gdb) p *repo
$1 = {
db = 0x0,
index = 0x0,
objects = 0x100448070,
path_repository = 0x0,
path_index = 0x0,
path_odb = 0x0,
path_workdir = 0x0,
is_bare = 0
}

I guess cleanup: needs to check if repo was actually initialized before calling git_repository_free()

GIT_COMMIT_GETTER fails assertion on in-memory commits

The GIT_COMMIT_GETTER macro tries to parse the object when commit->_name is NULL, which causes an assertion to fail when the object is in-memory. Reasonable behavior would be to return NULL for missing values on in-memory commits.

(Meta: I can fix this myself; should I bother creating issues in such cases?)

hardcoded ldconfig prevents compilation

on my Mac OS X 10.6.5, I can't compile libgit2 as of at least 5103518

I get this error:

/bin/sh: /sbin/ldconfig: No such file or directory

Please add a function to write an index as a tree rather than a commit

As far as I can tell, libgit2 allows committing an index, but not writing one as a tree without committing it (the equivalent of git write-tree). Please consider adding a function to write a tree object from an index.

Support for in-memory repositories

I came up with the idea of in-memory git repositories a few years ago, but I have never started implementing it. It may sound a bit weird, but it can be useful in some cases, especially when application doesn't need to save history across subsequent runs.

I haven't really looked into libgit2 code, but I see at least 2 approaches to solve the problem:

• moving all current fs operations to filesystem storage back-end implementation and replacing their use with generic storage back-end calls, later implementing memory storage back-end,
• making all currently fs-only operations explicitly extended to support working with objects in memory (by extending functions or providing their memory counterparts).

First one is more generic, but what storage back-ends can be used other than fs or mem? Using some db (e.g. sqlite, postgres) could be interesting. On the other hand supporting non-fs non-mem storage back-ends would require further decomposing how git data are stored and accessed, something maybe not necessary for mem storage back-end alone (after all we can just have bare "files" in memory), but also useful in that case if efficiency is important for us.

Second approach is less generic, but more flexible at the same time. This would allow having mixed (in terms of storage location) repositories. Imagine git repository on disk, but branch living only in memory, that still can be stored on disk or directly merged into master.

Possibilities are endless.

Windows build

libgit2 no longer builds on windows due to src/thread-utils.h relying on pthread.

It does look like some preproccessor magic could change the gitlck to use windows threads.

Setter/getter namespace

now the setter, getter functions in libgit2 look like this:

git_tree_entry_set_name
git_tree_entry_name

The first one tells me exactly that it is a setter for a field, while the other one could be function providing different functionality...
I wonder why they getters are not named like git_tree_entry_get_name

Memory leak when overwriting a reference

When you create a new reference with the name of an existing one, it replaces it and the pointer to this reference gets lost. I see two ways to go about solving these.

• The first one to simply free the old reference, like in carlosmn/libgit2@52de0279c77249e432f6
  • and the second one is to store them in order to avoid existing pointers to the old reference to point to freed memory, like in carlosmn/libgit2@43424c7520075be83069

The logic behind the new flag is that we could tell the user his reference has become old when he tries to use some git_reference_ function, but I'm not sure that it makes sense. The second branch still needs another patch or two 'till it's ready.

How do we expect references to be used? As a way to get an OID or would they be longer-lived?

segfault on git_object_lookup for repos with deep history

The git_object_lookup function produces a segmentation fault when applied to repositories with many commits. This can be reproduced using the Linux kernel (more than 240.000 commits).

Sample code:

#include <git2.h>
#define REPO "/home/jdavid/sandboxes/linux-2.6/.git"
#define SHA "9179746652faf0aba07b8b7f770dcf29892a24c6"

main()
{
  git_repository *repo;
  git_oid oid;
  git_object *commit;

  git_repository_open(&repo, REPO);
  git_oid_mkstr(&oid, SHA);
  git_object_lookup(&commit, repo, &oid, GIT_OBJ_COMMIT);  /* SEGFAULT */
}

open_repository() doesn't fail that graciously when being passed a wrong git repository path

When being passed

• an existing folder which is not a git repository
• a non existing folder

open_repository() doesn't return GIT_ENOTAREPO. Instead, the code chockes while trying to cleanup the database memory allocation (which hasn't be allocated yet). The issue is being raised by git_odb_close().

build a shared library?

Make install seems to be generating a static library, are there any plans for a shared lib?

tree.c's entry sorting algorithm is incorrect

Git sorts tree entries as if there were a / after tree node names. The end result of this bug is that git-status reports modified files in the index even when there are none, because apparently Git is quite sensitive to the ordering of entries in a tree.

I've fixed this in my updated pull request.

git__source_printf is broken

In git__source_printf, it tries one printf, and if this overflows the amount of available space, it resizes and then tries again. But if the second retry also overflows available space (and this does happen with long commit messages), it doesn't do another resize and retry.

Furthermore, it increases written_bytes by the number of bytes written by the first call to vsnprintf, not the second call made after the rewrite!

Actually, I'll try a fix for this and send another pull request. I think the answer is quite simple.

Use different name

As it doesn't look like libgit2 implements the "official" api, i think the project should use a different name (appending a "2" does not help).

Build Error on x64

I am not an expert in c++, but I figured I would ask to see if there is something that I am doing wrong.

The configure worked fine, it is the build-shared that is failing.

C:\rootdir\libgit2>python waf build-shared
Waf: Entering directory C:\rootdir\libgit2\build\shared' [ 1/23] c: src\blob.c -> build\shared\src\blob.c.0.o [ 2/23] c: src\delta-apply.c -> build\shared\src\delta-apply.c.0.o blob.c delta-apply.c [ 3/23] c: src\commit.c -> build\shared\src\commit.c.0.o commit.c [ 4/23] c: src\hash.c -> build\shared\src\hash.c.0.o hash.c ..\..\src\commit.c(291) : warning C4101: 'short_message' : unreferenced local variable [ 5/23] c: src\hashtable.c -> build\shared\src\hashtable.c.0.o [ 6/23] c: src\errors.c -> build\shared\src\errors.c.0.o errors.c hashtable.c [ 7/23] c: src\index.c -> build\shared\src\index.c.0.o [ 8/23] c: src\filelock.c -> build\shared\src\filelock.c.0.o index.c filelock.c ..\..\src\index.c(277) : warning C4244: '=' : conversion from '__time64_t' to 'unsigned int', possible loss of data ..\..\src\index.c(278) : warning C4244: '=' : conversion from '__time64_t' to 'unsigned int', possible loss of data ..\..\src\index.c(286) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data [ 9/23] c: src\fileops.c -> build\shared\src\fileops.c.0.o fileops.c [10/23] c: src\oid.c -> build\shared\src\oid.c.0.o oid.c [11/23] c: src\person.c -> build\shared\src\person.c.0.o person.c [12/23] c: src\odb.c -> build\shared\src\odb.c.0.o odb.c C:\rootdir\libgit2\src\git/zlib.h(5) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory Waf: Leaving directoryC:\rootdir\libgit2\build\shared'
Build failed
-> task failed (exit status 2):
{task 43901896L: c odb.c -> odb.c.0.o}
['C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\CL.exe', '/TC', '/W4', '/RTC1', '/nologo', '', '/IC:
!temp\libgit2\build\shared\src', '/IC:!temp\libgit2\src', '/IC:\Program Files (x86)\Microsoft Visual Studio 10
.0\VC\INCLUDE', '/IC:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ATLMFC\INCLUDE', '/IC:\Program Files (
x86)\Microsoft SDKs\Windows\v7.0A\include', '/DWIN32', '/D_DEBUG', '/D_LIB', '/DZLIB_WINAPI', '', '....\src\odb.
c', '/c', '/Fo', 'src\odb.c.0.o']

Please add functions for manipulating refs

Currently, libgit2 allows creating commits and tags, but it does not allow reading and writing refs from a repository. I'd like to use libgit2 to create, read, and destroy refs.

Needs a README

The info at http://libgit2.github.com is great, I'd love to see some of it in a README so that newcomers can get started (and point them to the website).

git_repository_init on an existing repository

I imagine that repo_init_reinit should not return GIT_SUCCESS while *repo_out still points to an undefined memory location.

Create and list branches/tags

How would one list all the branches/tags of a repository using this lib. If this is something that does not exist yet, will it be coming ?

git_index_write really slow

I have compared the performance of "git add" against an equivalent program using libgit2, and found libgit2 is very much slower than git.git (in my test case it was 0.6s instead of 0.06s). The slow operation is writing the index file (git_index_write).

Profiling and reading the code a little it looks the culprit is git_index__write. By the way, the code there is completely different from git.git's write_index, shouldn't libgit2 just copy & paste & adapt the git.git version?

The sample program is this:

#include <git2.h>
void main()
{
    git_repository *repo;
    git_index *index;

    git_repository_open(&repo, "XXX/.git");
    git_repository_index(&index, "XXX");
    git_index_read(index);
    git_index_add(index, PATH, 0);
    git_index_write(index);
}

More functions need to set git_errno

There are several functions in libgit2, especially those that return pointers, that don't provide any information about errors. For example, git_repository_open returns NULL when a git directory is invalid, but also when out of memory.

It would be great if we could count on any function that can cause an error to set git_errno. For functions that also return an error code, it should be possible to write a macro to set and return git_errno in one statement.

illegal memory access on `guess_repository_DIRs` when using relative path.

i found illegal memory access on guess_repository_DIRs when specified relative path.

# e.g
git_repository_open(&repository, "./.git/");

gitfo_prettify_dir_path convert "./.git/" to ".git/".
so below code will go to an unexpected memory.

https://github.com/libgit2/libgit2/blob/master/src/repository.c#L190

190:    while (*last_DIR != '/')
191:        last_DIR--;
                ^ unexpected memory access cause ".git/" string
                   does not have "/" char before ".".

I'm not good at C character processing yet. could you fix that code?

Kind regards,
Shuhei

git_repository_open() returns GIT_EINVALIDPATH when path contains double dots

Ex. "../repo/.git" or "../path/to/bare". Checked against the current development HEAD (20bf12d).

I tracked it down to this snippet in gitfo_prettify_dir_path().

/* Handle the double-dot upward directory navigation */
if (only_dots && segment_len == 2)
{
    current++;
    buffer_out -= segment_len;

    *buffer_out ='\0';
    len = retrieve_previous_path_component_start(buffer_out_start);
    if (len < GIT_SUCCESS)
        return GIT_EINVALIDPATH;

    buffer_out = (char *)buffer_out_start + len;
    continue;
}

git_odb_close vs. git_index_free

I've noticed that git_index_free makes sure the index is not bare using the git_repository pointer in the git_index struct, but git_odb_close doesn't do this, indeed no repository pointer exists in the git_odb struct. I've two questions about this :

(1) Is there any reason why git_odb structs should not know their repositories like indexes do? It appears that git_repository_open3 assigns the repository responsibility for freeing the git_odb struct, so presumably you'll never see a git_odb struct being used by multiple repositories.

(2) Is the convention moving towards "free" means free it immediately while "close" means it'll be free'd when it's safe to do so? If so, you might want to swap these function names to git_index_close and git_odb_free. Or call them both close if git_odb eventually gets a git_repository pointer.

git_index_entry -- staged?, not staged?, modified?

I am trying to determine what part of an index a index_entry is in (staged, not staged, modified, etc)

I was looking at git_index_entry::flags and git_index_entry::extended_flags, but can't find any documentation on it.

Simple application compiling error

Hello,

I compile libgit2 and install it in my computer. Now i try to compile simple application with libgit2:

#include <git2.h>

int main(int argc, char *argv[])
{
    git_repository *repo;
    git_repository_open(&repo, "/.git");
    git_repository_free(repo);
    return 0;
}

And get errors:

• error: undefined reference to `git_repository_open'
• error: undefined reference to `git_repository_free'

How can i fix it?

Thank you.

Functions to read and write objects (particularly blobs) incrementally

Currently, reading or writing a blob via libgit2 requires either using a file on disk or having the entire blob in an in-memory buffer. For large objects, or data getting sent or received over the network, it would help to have functions to incrementally read and write objects in chunks. This would apply most strongly to blobs; large trees seem like a lower priority, and large commits and tags seem quite unlikely to matter.

git_blob_rawcontent return type

The current prototype of git_blob_rawcontent is: const char *git_blob_rawcontent(git_blob *blob)

I think that the return type of git_blob_rawcontent should be (const void *), since blob->object.source.raw.data is (void *) and git_blob_set_rawcontent uses (const void *).

feature request: Support opening a repository with custom ODB backend or with a pre-created ODB.

Right now one can only add a custom backend to the ODB created by the git_repository, but that means the 'loose' & 'pack' backends are also tried for all backend requests.

git_index_entry* can't read path on ubuntu.

im tring to use libgit2 on my ubuntu 10.10.
i found Segmentation fault when try to read git_index_entry->path.

git clone https://github.com/libgit2/libgit2.git
cd libgit2
./waf configure
./waf build-shared
sudo ./waf install-shared

cat > git_index_test.c <<EOF
#include <stdio.h>
#include <git2.h>

int main(int argc, char * args[])
{
    git_index_entry *entry;
    git_index *index;
    git_index_open_bare(&index,".git/index");

    git_index_read(index);
    git_index_entrycount(index);
    int offset = git_index_find(index,"README.md");

    entry = git_index_get(index,offset);

    printf("pointer_address: %d\n", entry->path);
    //Segmentation fault on my machine.
    printf("path: %s\n",entry->path);
    git_index_free(index);

    return 0;
}
EOF

gcc -lgit2 -o git_index_test git_index_test.c

./git_index_test
pointer_address: 9
Segmentation fault

I searched reason. but i couldn't understand.
git_index_entry->path readable in git_index_get(). but git_index_entry->path was wrong address in main.

(but ruggaed work well on my machine.probably i missunderstood something...)

Could you please advice me how to fix this probrem?

$ gcc -v
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 

Please support creating an in-memory index file for an on-disk repository

libgit2 only seems to support two ways of creating an index: as a file on disk associated with an on-disk repository, or as an in-memory representation of a standalone index file unattached to an on-disk repository. The latter kind of index doesn't support writing objects (git_index_add). I'd like to use an index to write out objects to an on-disk repository, but I'd like to keep the index in memory without creating a temporary file. Please consider adding a way to construct an in-memory index with no backing index file, associated with an on-disk repository.

user/email hardcoded limited to length of 64

If this is a hardcoded limit in git it should be moved to a define rather than have 64 is several spots in the code. If it is not a limit it should be fixed.

Maybe an error in guess_repository_DIRs

Hello,

I worked this morning on the bug #61 and it's fixed now (thanks to Vicent Martí) but i maybe found an other bug during this.

I used valgrind to localize the first bug and a part of its output is:
==7116== Source and destination overlap in memcpy(0xbead2ee0, 0xbead2ee0, 11)
==7116== at 0x4025E1F: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==7116== by 0x403AC1D: git__dirname_r (util.c:143)
==7116== by 0x4037BC8: guess_repository_DIRs (repository.c:217)
==7116== by 0x4037FE2: git_repository_open (repository.c:356)
==7116== by 0x8048709: main (test.c:13)

git__dirname_r is used with the same variable for buffer and path, that can be an error, but ok, i don't know enough your code to say that.

Best regards,
D. Versmisse.

HEAD lookup?

I created some .NET bindings and found myself in a situation that I couldn't get the git_reference for HEAD with git_reference_lookup. First I thought it was my fault, or the fault of .NET marshalling strings, but I then created a little C app to verify that behavior.

#include <git2.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  int error;
  git_repository *repo;

  char *refname = "HEAD";

  if (argc > 1)
    refname = argv[1];

  error = git_repository_open(&repo, "testrep.git/.git/");

  if (error < 0) {
    printf("%s\n", git_strerror(error));
    return error;
  }

  git_reference *ref;

  error = git_reference_lookup(&ref, repo, refname);
  if (error < 0) {
    printf("%s\n", git_strerror(error));
    return error;
  }

  printf("%s exists!\n", refname);

  git_repository_free(repo);

  return 0;
}

And indeed, it still wouldn't work, I couldn't lookup HEAD.
Or maybe I am doing something wrong?