Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[RFC] transition to gitoxide #112

Closed
wants to merge 2 commits into from
Closed

[RFC] transition to gitoxide #112

wants to merge 2 commits into from

Commits on May 17, 2022

  1. [RFC] transition to gitoxide 

    This PR shows how a first step towards transitioning to `gitoxide` could
look like.

It adds a `gitoxide` feature toggle which if set uses `gitoxide` to fill
in all `git` related values. It works additively.

The best way for me to see how useful `gitoxide` is for applications and
libraries is to seek out mature projects that use `git2` and see how
`gitoxide` fits in there. `vergen` was special as it brought the notion
of MSRV support into [`gitoxide''s understanding of
stability](https://github.com/Byron/gitoxide/blob/498072ea42dca7b9d00bedba42829bdac92195b9/STABILITY.md#L124)
and required it to run on and work on various targets that aren't
typically tested in its own CI.

Users of `vergen` expect stability and compilation in a variety of
environment and `gitoxide` wants to cater to that.

- `gitoxide` is generally faster than `git2` and uses less system
  resources.
- `gitoxide` aims to support all features of `git` focussing on
  correctness, usability and performance, in that order.
- `gitoxide` supports a minimal pure Rust build.
- In case of issues, one deals with only a single project, whereas with
  `git2` there is `libgit2` and `git2`.
- `gitoxide` guarantees to hide breaking changes behind major/minor
  version bumps to never break downstream. Changing the MSRV is
  considered a breaking change. All this is described in the
  [Stability
  Guide](https://github.com/Byron/gitoxide/blob/498072ea42dca7b9d00bedba42829bdac92195b9/STABILITY.md).
- The maintainers of `gitoxide` are happy to maintain the `gitoxide`
  integration until it's first major release.

- after the transition period a major version bump for `vergen` is
  required to allow removing the `gitoxide` feature toggle, unless it
  should stay a no-op.
- compile times for `gitoxide` are higher overall.
- …there is probably more that I can't think of.

What's missing is to obtain a worktree status, effectively a diff
between index and worktree, to support the optional 'dirty' suffix
in the semver description key.

The above is a writeup of all I know about this transition, and I hope
it can serve as foundation for figuring out how (or if) to proceed with
this.

Thanks for sharing your thoughts.
    @Byron @CraZySacX
    Byron authored and CraZySacX committed May 17, 2022
    Configuration menu
    Copy the full SHA
    9be7eee View commit details
    Browse the repository at this point in the history

  2. uprgade to latest gitoxide release 

    Maybe it's better to refer to a stable version from crates now.
    @Byron @CraZySacX
    Byron authored and CraZySacX committed May 17, 2022
    Configuration menu
    Copy the full SHA
    dad7a76 View commit details
    Browse the repository at this point in the history