Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/
