Re: [PATCH v2 0/5] Introduce cgit-rs, a Rust wrapper around libgit.a

> On 2024.08.12 05:03, Eric Sunshine wrote:
> > On Mon, Aug 12, 2024 at 4:15 AM Junio C Hamano <gitster@pobox.com> 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.