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

Eric Sunshine <sunshine@sunshineco.com> writes:

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.

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.

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.