On 2024.08.12 05:03, Eric Sunshine wrote:
> On Mon, Aug 12, 2024 at 4:15 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > The original iteration had this:
> >
> > * bikeshedding on the name (yes, really). There is an active, unrelated
> > CGit project [4] that we only recently became aware of. We originally
> > took the name "cgit" because at $DAYJOB we sometimes refer to git.git
> > as "cgit" to distinguish it from jgit [5].
>
> A tangent: Speaking of external/other projects, I don't think we've
> seen an explanation yet as to why this Rust wrapper is proposed as a
> `contrib/` item of Git itself, as opposed to being a separate project.
>
> I can only think of two possible reasons why they might want it in the
> Git project itself...
>
> (1) Easier access to the library portions of Git ("libgit") since that
> portion of the code is not otherwise published as a standalone
> library. However, a workable alternative would be for the Rust wrapper
> to carry its own "vendored"[1] copy of Git. This would also ensure
> more reliable builds since they wouldn't have to worry about the
> "libgit" API changing from under them, and can adjust for "libgit" API
> changes when they manually pull in a new vendored copy. Hence, I'm not
> convinced that this is a valid reason to carry the Rust wrapper in
> Git.
>
> (2) Perhaps the intention is that this Rust wrapper work will allow
> Rust to be used within Git itself[3]? If that's the case, then
> `contrib/` seems the wrong resting place for this code.
Neither, actually. We hope that by keeping the crate definition in the
main Git repo and by allowing developers to optionally run them by
default as part of CI and `make test`, we can catch breaking bugs as
early as possible. We're also hoping that we'll get more attention from
interested developers by staying in the main repo rather than in a
separate project.
> On the other hand, as a standalone project, a big benefit is that the
> Rust wrapper could have its own release cadence distinct from Git,
> which would likely be very beneficial since it is such a young
> (indeed, nascent) library; it is likely that the maintainers will want
> to release early and often at this stage.
AFAIK, the crate releases don't have to be strictly tied to Git
releases. In theory we could choose to publish updates to the crate
whenever "master" or any other branch is updated; whether or not that is
a good idea is a separate discussion.
> [1]: Other Rust projects carry vendored copies of projects upon which
> they rely. For instance, the "native_tls" crate has a vendored copy of
> OpenSSL[2].
>
> [2]: https://docs.rs/native-tls/latest/native_tls/#cargo-features
>
> [3]: https://lore.kernel.org/git/CABPp-BFWsWCGogqQ=haMsS4OhOdSwc3frcAxa6soQR5ORTceOA@xxxxxxxxxxxxxx/
