12,009 stars · Dual Apache-2.0 and MIT, both read from the files at /blob/main/LICENSE-APACHE and /blob/main/LICENSE-MIT; both plain, and the MIT file carries NO copyright line at all while its own text requires the notice be retained · gix-utils-v0.5.1 (2026-10-11), read from /releases/latest and matched to the second by crates.io, which dates the same version 2026-10-11T08:14:26Z; the project releases its gix-* crates individually, so the newest tag is one workspace crate and not a whole-project version · Track this in Scout
Git written again from scratch as a library other programs can build on, with its own gaps written down.
▶Repo detailsthe review · specs · pros & cons · install
What it does
The main piece is a library, meaning code you call from your own program rather than something you open. It reads and writes a real git folder on disk: the stored objects, the branch names, the index of staged files, the settings, the ignore rules and the commit history. It also speaks the protocols git uses to talk to a server, so it can clone and fetch. Two command-line programs come with it: one for everyday use and one of low-level plumbing commands. Today it covers cloning, fetching, status, blame, comparing files and folders, merging file contents and folder trees, committing, and checking out a working copy. What it does not do is listed plainly in its own files: push, merging whole commits, rebase and reset are not implemented, commit hooks are not done, and the README warns that the command-line tools are development aids and that you should "not rely on them in scripts".
Why it matters
Who it suits. People writing software that handles git repositories and who do not want to shell out to the git command or link a C library. The published limits are unusually specific, so you can tell in ten minutes whether your use is covered. Skip it if you need push, rebase or reset, and skip it if you were hoping for a faster drop-in replacement for the git command you type every day, because that is not what this is.
Verdict. This is the most honest README in today's twelve, and that is the reason to take it seriously. A separate file lists its own shortcomings, including that fetches over the older protocol with a stateful connection "may hang", that pack files are read through memory maps which "squelch IO errors", and that files above two or four gigabytes cannot be loaded on a 32-bit machine. Two of its crates are declared stable and the rest are not. That combination — pre-1.0, with the gaps written down rather than discovered — is far safer to build on than a project that promises everything. If you want a finished tool today rather than a foundation, libgit2/libgit2 is the C library everything else already uses, and rust-lang/git2-rs wraps it for Rust.
- A separate file in the repository lists its own weaknesses, with specifics rather than apologies.
- Dual Apache-2.0 and MIT licences, both read from the files, with nothing added to either.
- Code landed on the morning of this edition, and the project has been going since June 2018.
- Push, rebase, reset and merging whole commits are not implemented, and commit hooks are not done.
- Pre-1.0 and expected to stay there for a while: only two of its many crates are declared stable.
- The MIT licence file carries no copyright line at all, while its own text requires that the copyright notice be kept.
- libgit2/libgit2
The long-established C library that most git integrations already use; complete where this is not, and C rather than Rust.
Track this in Scout - rust-lang/git2-rs
The Rust wrapper around libgit2, which is the practical alternative today if you need push and rebase.
Track this in Scout - go-git/go-git
The same idea in Go: git implemented from scratch as a library rather than wrapping the original.
Track this in Scout
# Prebuilt binaries, the easy route cargo binstall gitoxide # Or from source, which needs cmake cargo install gitoxide # Or a build that needs only Rust and a C compiler cargo install gitoxide --locked --no-default-features --features max-pure