A first usable version of `git-repository` to make using `gitoxide` from your applications so much easier. It serves as a one-stop shop for application developers without sacrificing performance by default while making common use-cases more convenient. ### Feature list * `git-repository` as hub crate for application development with focus on usability without sacrificing any knob to tune performance. * opt-in `async` for `git-packetline`, `git-transport` and `git-protocol` for fully async git clients, along with the `light-async` feature toggle to build a `gixp pack-receive` with an async client instead of a blocking one. * Statistics for `gixp pack-create` with the `-s/--statistics` flag to have data indicating the cost of the operation. Currently it's doing a lot of work that has to be avoided in order to be useable in production and the numbers underline that. Future iterations will cause key metrics to go down. * Packs are now reproducible by default, which means that the same tip will always generate a pack with the same hash. This may be a desirable property for some kinds of packs, but not for others which is why it can be turned off for a considerable speed boost. * `git-tempfile` crate * `git-lock` crate * `git-ref` crate with complete loose-ref, packed-ref and transaction support. ### Performance * On M1, thanks to [a new release](https://github.com/RustCrypto/hashes/pull/289#event-5035369215), Sha1 is now computed much faster which unlocks a massive performance boost. In my test, verifying/decoding the entire linux kernel pack now happens in 17s, as compared to 37s for canonical `git`. * `git-object` parsing is a few percent faster thanks a reworked error handling for objects. By default, error collection is disabled entirely making the error case zero-sized. If needed, verbose and stacked errors can be turned on using a feature toggle for applications who expect repositories with malformed objects and need detailed diagnostics. ### New Features - control pack and object cache size in megabytes in some sub-commands ### Commit Statistics - 4 commits contributed to the release over the course of 26 calendar days. - 1 commit where understood as [conventional](https://www.conventionalcommits.org). - 2 unique issues were worked on: #200, #67