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.
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.
[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/
