gix is a command-line interface (CLI) to access git repositories. It's written to optimize the user-experience, and perform as good or better than the canonical implementation.
Furthermore it provides an easy and safe to use API in the form of various small crates for implementing your own tools in a breeze. Please see 'Development Status' for a listing of all crates and their capabilities.
gitoxide-corelibrary, which mirrors these capabilities and itself relies on all
einprogram - convenient and for humans
gixprogram (plumbing) - lower level commands for use in automation
git worktree, providing flexible options to evaluate checkout performance from an index and/or an object database.
Follow linked crate name for detailed status. Please note that all crates follow [semver] as well as the stability guide.
Crates that seem feature complete and need to see some more use before they can be released as 1.0.
Many crates use feature flags to allow tuning the compiled result based on your needs. Have a look at the guide for more information.
Our stability guide helps to judge how much churn can be expected when depending on crates in this workspace.
Then install gitoxide with
cargo quickinstall 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.
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.
The minimum supported Rust version is documented in the CI configuration, the latest stable one will work as well.
# The default installation, 'max' cargo install gitoxide # For smaller binaries and even faster build times that are traded for a less fancy CLI implementation, use `lean` # or `lean-termion` respectively. cargo install gitoxide --no-default-features --features lean
The following installs the latest unpublished release directly from git:
cargo install --git https://github.com/Byron/gitoxide gitoxide
Once installed, there are two binaries:
Project goals can change over time as we learn more, and they can be challenged.
GitPythonin the process.
anyhow::Errorexhaustively, knowing these errors are solely user-facing.
Project non-goals can change over time as we learn more, and they can be challenged.
gitcommand functionality perfectly
git, and there is no reason to not use it. Our path is the one of simplicity to make getting started with git easy.
blockingas well as
git-features::interruptto bring operations into the async world and to control long running operations.
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.
We recommend running
make tests check-size during the development process to assure CI is green before pushing.
A backlog for work ready to be picked up is available in the Project's Kanban board, which contains instructions on how to pick a task. If it's empty or you have other questions, feel free to start a discussion or reach out to @Byron privately.
For additional details, also take a look at the collaboration guide.
gitoxideitself which should be a good foundation for any contribution, but isn't a requirement for contributions either.
Provide a CLI to for the most basic user journey:
gix tool open-remoteopen the URL of the remote, possibly after applying known transformations to go from
tixas example implementation of
tig, displaying a version of the commit graph, useful for practicing how highly responsive GUIs can be made.
git-tuishould 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.
git-lfsto 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.
argh, which does not yet support parsing OsStrings. We however believe it eventually will do so and thus don't move on to
argh, which forces porcelain to limit itself as well despite using
clap. We deem this acceptable for plumbing commands and think that porcelain will be high-level and smart enough to not ever require deeply nested sub-commands.
gititself, allowing our implementation to be simpler and potentially more performant.
izip!macro in code
This project is licensed under either of
at your option.
gitoxideit will be possible to provide the fastest solution for it.
gitfrom 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!