Crate gitoxide_core

source ·
Expand description

The purpose of this crate is to abstract the user interface of gix (the command-line interface) from the actual implementation. That way, one day it’s possible to provide alternative frontends, including user interfaces.

§What is gix?

gix is a tool to aid developers of gitoxide run their code in real-world situations and to validate the gix API. This makes it more of a test-bed than a tool that could ever rival git in terms of feature-set.

That said, gix may actively carve out a niche for itself where it sees the greatest benefits for users of git.

§This crate is internal - use gix instead.

It’s important to understand that this crate consider itself an implementation detail of the gix CLI and is not meant to be used for external consumption by means of cargo dependency. This is emphasized by there being no other documentation. There is also no intention of ever stabilizing this crate.

If you want to get started with what powers gix, please take a look at the gix crate which provides all the building blocks to create any application, including a carbon-copy of git itself (at least aspirationally as not all capabilities are available in gix yet).

For users of gix, this codebase might serve as elaborate example as most of not all of its APIs are used here.

§Feature Flags

§Tools

  • organize — Discover all git repositories within a directory. Particularly useful with skim.
  • estimate-hours — Derive the amount of time invested into a git repository akin to git-hours.
  • query — Gather information about repositories and store it in a database for easy querying.
  • corpus — Run algorithms on a corpus of repositories and store their results for later comparison and intelligence gathering. Note that organize we need for finding git repositories fast.
  • archive — The ability to create archives from virtual worktrees, similar to git archive.
  • clean — The ability to clean a repository, similar to git clean.

§Mutually Exclusive Networking

If both are set, blocking-client will take precedence, allowing --all-features to be used.

  • blocking-client — If set, the client used to connect to git servers will use a blocking API. It supports more transports and is what most would want.
  • async-client — The client to connect to git servers will be async, while supporting only the ‘git’ transport itself. It’s the most limited and can be seen as example on how to use custom transports for custom servers.

§Other

  • serde — Data structures implement serde::Serialize and serde::Deserialize.

Modules§

Enums§

Functions§