gix-macros-v0.2.1gix-macros v0.2.1最新正式版2026-11-02 · 2026-11-02 08:37 UTC
New Features
gate experimental APIs with introduction dates
A stable API needs to retain internal access to experimental items while making
those items an explicit opt-in for downstream consumers. Cargo feature unification
also means API checks must distinguish experimental members even when compiled
with the feature enabled.
Add unstable for items, inherent methods and trait implementations, plus
unstable_fields for selected public fields. Disabled gates retain crate-private
access where Rust permits it; trait implementations are omitted instead. Support
file-backed modules on Rust 1.88 through inline bodies with include!;
applying the attribute directly to pub mod name; requires Rust 1.99.
Require since = "YYYY-MM-DD" with the item's introduction date from Git history.
Validate calendar dates and include them in the generated instability marker.
Keep reason optional and nonempty when supplied, for explanations beyond the
signature or the fact that an item is experimental.
Cover visibility, fields, trait implementations, documentation, missing and
malformed dates, leap years and centuries, and invalid or duplicate arguments.
The fixtures use their introduction dates from Git history.
0 issues like '(#ID)' were seen in commit messages
Commit Details
Uncategorized
Merge pull request #3061 from GitoxideLabs/stable-gix (5c88568)
Gate experimental APIs with introduction dates (56c12b6)
Merge pull request #3020 from GitoxideLabs/report-september (5fb3dcf)
gix-testtools-v0.22.0gix-testtools v0.22.02026-10-24 · 2026-10-24 16:08 UTC
查看更新说明
Chore
make docs-rs work, and publishing
New Features
add rename() for replacing read-only fixture files
I removed a lot of tests for that, assuming it's trivial enough to get right
and existing tests that use it are proof of function enough.
Git creates read-only commit-graph files. On Windows, this also prevents
replacing them with std::fs::rename(), requiring fixture setup to clear
the destination's read-only attribute first.
Add gix_testtools::rename() to retry permission-denied renames after
clearing that attribute. Other platforms retain std::fs::rename()
behavior. Document that callers must use writable fixtures or fixture
initialization and release memory mappings before replacing backing files.
Trace Bash fixture commands without changing captured baselines
A flaky Windows fetch test failed while generating make_remote_repos.sh,
before the worktree assertions ran. The fixture output stopped after cloning
credential-helpers, leaving no failing command or process exit status to
explain the abort. Expected merge conflicts earlier in the script further
obscured where setup actually failed.
Enable set -x by default for .sh fixtures on Bash 4.1 and newer. Route
traces through BASH_XTRACEFD to a duplicate of the original stderr, so
commands that redirect stderr into fixture baselines do not capture tracing
output. Keep successful fixture generation quiet by retaining the runner's
existing policy of printing captured output only on failure.
Bash 3.2, including the version shipped with macOS, cannot redirect xtrace
independently of stderr. Use an inherited ERR trap there to report the
failed command, script location, and status through the same descriptor.
Include the subprocess exit status in the runner's error on every platform.
Add coverage for silent command lookup failures, unchanged redirected stderr
baselines, and exit statuses in fixture errors. This improves diagnosis; it
does not identify or fix the original Windows flake.
add symlink preflight for Bash fixtures
Careful refackiew, only the tests were mostly waved through as they
are known to be super thorough. Only their style needs checking, which
was fine here.
Fixtures that require symbolic links need to distinguish unavailable symlink
creation on the host from broken fixture setup. Otherwise, tests either fail
on unsupported filesystems or risk hiding unrelated errors when skipping.
Inject gix_testtools_require_symlinks into Bash fixtures to probe creation
of a real link before generating contents. Record the outcome at the fixture
root and stop successfully when links are unavailable. Tests can then use
fixture_has_symlinks() to skip explicitly; missing or malformed results,
unexpected ln exits, copied files, and later setup failures remain errors.
Preserve script arguments and Bash 3.2 source context without exporting the
helper to child shells. Include the prelude in cache keys for fixtures using
the probe, and document archive and writable-fixture constraints.
redact unstable values in diagnostic snapshots
Complete error snapshots expose useful context and causes, but temporary
paths, dynamically assigned ports, object IDs, and platform-specific I/O
messages make their output unstable.
Add redact_debug_snapshot() to apply explicit replacements, reuse object-ID
normalization, and render OS errors by their portable ErrorKind. Handle
plain and debug-escaped Windows paths while retaining meaningful suffixes
and unrelated backslashes. Return an owned Debug value so insta displays
the diagnostic without additional quoting or newline escaping.
Cover redaction, object identity, and OS error formatting, and convert the
environment,
gix-sec-v0.16.1gix-sec v0.16.12026-10-24 · 2026-10-24 16:08 UTC
查看更新说明
Commit Statistics
3 commits contributed to the release over the course of 16 calendar days.
gitoxide is an implementation of git written in Rust for developing future-proof applications which strive for correctness and
performance while providing a pleasant and unsurprising developer experience.
There are two primary ways to use gitoxide:
As Rust library: Use the gix crate as a Cargo dependency for API access.
As command-line tool: The gix binary as development tool to help testing the API in real repositories,
and the ein binary with workflow-enhancing tools. Both binaries may forever be unstable,
do not rely on them in scripts.
Development Status
The command-line tools as well as the status of each crate is described in
the crate status document.
For use in applications, look for the gix crate,
which serves as entrypoint to the functionality provided by various lower-level plumbing crates like
gix-config.
Feature Discovery
Can gix do what I need it to do?
The above can be hard to answer and this paragraph is here to help with feature discovery.
Look at crate-status.md for a rather exhaustive document that contains
both implemented and planned features.
Further, the gix crate documentation with the git2 search term helps to find all currently
known git2 equivalent method calls. Please note that this list is definitely not exhaustive yet, but might help if you are coming from git2.
What follows is a high-level list of features and those which are planned:
clone
fetch
push
blame (plumbing)
status
blob and tree-diff
merge
blobs
trees
commits
commit
hooks
commit-graph traversal
rebase
worktree checkout and worktree stream
reset
reading and writing of objects
reading and writing of refs
reading and writing of .git/index
reading and writing of git configuration
pathspecs
revspecs
.gitignore and .gitattributes
Crates
Follow linked crate name for detailed status. Please note that all crates follow semver as well as the stability guide.
Crates whose chosen supported public API is nearly ready for a 1.0 compatibility commitment.
Remaining experimental public APIs can stay behind a non-default unstable feature.
Documentation for the supported API is complete and was reviewed at least once.
A major-zero crate (0.x) may introduce breaking API changes in minor releases. This says nothing about its
quality, completeness, or suitability for production use. Crates used only as implementation details, without
exposing their APIs through public crates, may remain major-zero crates indefinitely.
usable(with rough but complete docs, possibly incomplete functionality)
Our stability guide helps to judge how much churn can be expected when depending on crates in this workspace.
Installation
Download a Binary Release
Using cargo binstall, one is able to fetch binary releases. You can install it via cargo install cargo-binstall, assuming
the rust toolchain is present.
Then install gitoxide with cargo binstall gitoxide.
See the releases section for manual installation and various alternative builds that are slimmer or smaller, depending
on your needs, for Linux, MacOS and Windows.
Install with Homebrew
For macOS and Linux, gitoxide can be installed from Homebrew:
brew install gitoxide
Download from Arch Linux repository
For Arch Linux you can download gitoxide from community repository:
pacman -S gitoxide
Download from Exherbo Linux Rust repository
For Exherbo Linux you can download gitoxide from the Rust repository:
cargo is the Rust package manager which can easily be obtained through rustup. With it, you can build your own binary
effortlessly and for your particular CPU for additional performance gains.
There are various build configurations, all of them are documented here. The documentation should also be useful
for packagers who need to tune external dependencies.
# A way to install `gitoxide` with just Rust and a C compiler installed.
# If there are problems with SSL certificates during clones, try to omit `--locked`.
cargo install gitoxide --locked --no-default-features --features max-pure
# The default installation, 'max', is the fastest, but also needs `cmake` to build successfully.
# Installing it is platform-dependent.
cargo install gitoxide
# For smaller binaries and even faster build times that are traded for a less fancy CLI implementation,
# use the `lean` feature.
cargo install gitoxide --locked --no-default-features --features lean
The following installs the latest unpublished max release directly from git:
On Fedora, perl needs to be installed for OpenSSL to build properly. This can be done with the following command (see issue #592):
dnf install perl
Using Docker
Some CI/CD pipelines leverage repository cloning. Below is a copy-paste-able example to build docker images for such workflows.
As no official image exists (at this time), an image must first be built.
[!NOTE]
The dockerfile isn't continuously tested as it costs too much time and thus might already be broken.
PRs are welcome.
high level commands, porcelain, for every-day use, optimized for a pleasant user experience
gix
low level commands, plumbing, for use in more specialized cases and to validate newly written code in real-world scenarios
Project Goals
Project goals can change over time as we learn more, and they can be challenged.
a pure-rust implementation of git
including transport, object database, references, cli and tui
a simple command-line interface is provided for the most common git operations, optimized for
user experience. A simple-git if you so will.
be the go-to implementation for anyone who wants to solve problems around git, and become
the alternative to GitPython and libgit2 in the process.
become the foundation for a distributed alternative to GitHub, and maybe even for use within GitHub itself
learn from the best to write the best possible idiomatic Rust
libgit2 is a fantastic resource to see what abstractions work, we will use them
use Rust's type system to make misuse impossible
be the best performing implementation
use Rust's type system to optimize for work not done without being hard to use
make use of parallelism from the get go
sparse checkout support from day one
assure on-disk consistency
assure reads never interfere with concurrent writes
assure multiple concurrent writes don't cause trouble
take shortcuts, but not in quality
binaries use gix::Result and gix::Error to preserve error context and source locations, with helpers available through gix::error instead of a separate gix-error dependency.
libraries use light-weight custom errors implemented using quick-error or thiserror.
internationalization is nothing we are concerned with right now.
IO errors due to insufficient amount of open file handles don't always lead to operation failure
Cross platform support, including Windows
With the tools and experience available here there is no reason not to support Windows.
Project non-goals can change over time as we learn more, and they can be challenged.
replicate git command functionality perfectly
git is git, and there is no reason to not use it. Our path is the one of simplicity to make
getting started with git easy.
be incompatible to git
the on-disk format must remain compatible, and we will never contend with it.
use async IO everywhere
for the most part, git operations are heavily reliant on memory mapped IO as well as CPU to decompress data,
which doesn't lend itself well to async IO out of the box.
Use blocking as well as gix_utils::interrupt to bring operations into the async world and to control
long running operations.
When connecting or streaming over TCP connections, especially when receiving on the server, async seems like a must
though, but behind a feature flag.
Contributions
If what you have seen so far sparked your interest to contribute, then let us say: We are happy to have you and help you to get started. What's paricularly welcome is the discovery of deviations from Git, or the prodding
and probing to find bugs and other forms of undesirable behaviour.
Please read the contribution guide before starting. It covers when prior discussion is required and how to prepare a submission.
A truly awesome history rewriter which makes it easy to understand what happened while avoiding all pitfalls. Think BFG, but more awesome, if that's possible.
gix-tui should learn a lot from fossil-scm regarding the presentation of data. Maybe this can be used for prompts. Probably magit has a lot to offer, too.
Ideas for Spin-Offs
A system to integrate tightly with gix-lfs to allow a multi-tier architecture so that assets can be stored in git and are accessible quickly from an intranet location
(for example by accessing the storage read-only over the network) while changes are pushed immediately by the server to other edge locations, like the cloud or backups. Sparse checkouts along with explorer/finder integrations
make it convenient to only work on a small subset of files locally. Clones can contain all configuration somebody would need to work efficiently from their location,
and authentication for the git history as well as LFS resources make the system secure. One could imagine encryption support for untrusted locations in the cloud
even though more research would have to be done to make it truly secure.
A syncthing like client/server application. This is to demonstrate how lower-level crates can be combined into custom applications that use
only part of git's technology to achieve their very own thing. Watch out for big file support, multi-device cross-syncing, the possibility for
untrusted destinations using full-encryption, case-insensitive and sensitive filesystems, and extended file attributes as well as ignore files.
An event-based database that uses commit messages to store deltas, while occasionally aggregating the actual state in a tree. Of course it's distributed by nature, allowing
people to work offline.
It's abstracted to completely hide the actual data model behind it, allowing for all kinds of things to be implemented on top.
Commits probably need a nanosecond component for the timestamp, which can be added via custom header field.
having recording all changes allows for perfect merging, both on the client or on the server, while keeping a natural audit log which makes it useful for mission critical
databases in business.
Applications
Can markdown be used as database so issue-trackers along with meta-data could just be markdown files which are mostly human-editable? Could user interfaces
be meta-data aware and just hide the meta-data chunks which are now editable in the GUI itself? Doing this would make conflicts easier to resolve than an sqlite
database.
A time tracker - simple data, very likely naturally conflict free, and interesting to see it in terms of teams or companies using it with maybe GitHub as Backing for authentication.
How about supporting multiple different trackers, as in different remotes?
We use the high-level flate2 library to implement decompression and compression, which builds on the high-performance zlib-rs crate.
🙏 Special Thanks 🙏
At least for now this section is exclusive to highlight the incredible support that Josh Triplett has provided to me
in the form of advice, sponsorship and countless other benefits that were incredibly meaningful. Going full time with gitoxide would hardly have been
feasible without his involvement, and I couldn't be more grateful 😌.
Originally @Byron was really fascinated by this problem
and believes that with gitoxide it will be possible to provide the fastest solution for it.
@Byron has been absolutely blown away by git from the first time he experienced git more than 13 years ago, and
tried to implement it in various shapes and forms
multiple times. Now with Rust @Byron finally feels to have found the right tool for the job!
