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

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

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

This is not a good reason at all, if we look at what (the real) cgit
project does ;-), which is to bind us as their submodule.

> (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.

The contrib/ hierarchy is a mixed bag, and we may want to clean it
up by Git 3.0 happens.

 - We used to put things that one-way depend on Git that are (1)
   useless by themselves, if Git did not exist, and (2) Git can do
   fine without them in the contrib/ hierarchy.

   The primary reason for doing so was because the Git was young and
   relatively unknown, and our community was small.  Even for an
   add-on that may be at most "nice to have" from Git's point of
   view, it made some sense to give these add-ons wider exposure by
   simply being bundled with Git.  We stopped doing that after Git
   ecosystem have matured enough and encouraged them to move either
   up (i.e. prove that Git cannot really do fine without it because
   the add-on is so useful, and become the first class part of Git)
   or out (i.e. it may be a fine add-on, but there are other similar
   add-ons that aim to achieve the same, similar, or overlapping
   goal---unlike the nascent era of Git, it should be able to become
   an independent project to compete fairly with others on its merit
   alone).

 - We have some stuff like completion and prompt scripts that have
   proven that the end-user experience cannot be "fine without", but
   haven't moved out of "contrib/", mostly by inercia.

 - We also have things that are meant to help Git developers in the
   hierarchy (Cocci rules come to mind).  This one could fall into
   that category, but I am not sure.

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

That's cgit approach.  If something is useless if Git did not exist,
but Git does not need it at all to function, that may be a sensible
thing to do.

If we plan to eventually be able to rewrite the logic for say
history traveral or specifying "set of commits" in such a way that
is more involved than just "those that can be reached from these tip
commits excluding the ones that can be reached from those bottom
commits" (in other words, "A..B C..D" that is not "^A B ^C D"), and
find it unpleasant to do in C and want to employ Rust, for example,
we'd certainly need it somewhere in _our_ tree.  Perhaps by the time
it happens we might have an extension/dll mechanism in such a way
that those who do not want (or cannot build) certain extensions can
opt out and these "optional" things would by convention live
somewhere other than the main source code live, but even then,
contrib/ sounds like a wrong place and we'd do so perhaps in extra/
or something.

> [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@mail.gmail.com/