Re: [Administrivia] On ruby and contrib/

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

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> * Ask the user to build external programs with
>
>   make GIT_ROOT=where/git/lives/
>
> * or, ask users to checkout the external program as a subdirectory of
>   git.git to build it (for example, clang's build installation ask you
>   to put clang as a subdirectory of LLVM's tree).
>
>> But my main point is that I think it would be easier to phase out
>> contrib/ if there were a good alternate way of providing visibility to
>> "satellite" projects. [...] Perhaps ranking
>> the tools based on the results of the Git user surveys would help bring
>> the most popular to the top of each category.
>
> I think this is the most important point. A good example would be
> git-multimail: for now, the shell version in contrib/ is somehow
> considered as the official hook to send emails, just because it is in
> contrib, while git-multimail is clearly superior (unless you don't have
> a python interpreter on your server).

I was envisioning to sift what are in contrib/ into these four
categories:

 (1) Ones that deserve to be Git subcommands;

 (2) Ones that are useful only in the context of using Git
     (e.g. hooks, completion scripts, credential and remote helpers);

 (3) Ones that are no longer useful;

 (4) Ones that primarily _use_ Git, not the other way around
     (i.e. opposite of category (2) which help use of Git).

The first category will live next to git-am.sh (i.e. in the longer
term when we restructure the source tree into src/, lib/, etc.,
candidates for new scripted subcommands move with the scripted
Porcelains).

The second category will be in a separate hierarchy (perhaps
addons/, hooks/, ..., but I am fine if we decide to keep them in
contrib/addons, contrib/hooks, etc.).

The last two categories will be removed; people are welcome to
decide which category between (3) and (4) each piece belongs to, and
pick up to start a standalone third-party project.

The multimail tool can be in the second category.  It helps use of
Git more than it is helped by using Git.

> I'm not opposed to Junio's proposal to restrict contrib/ (although a bit
> reluctant), but I think this should be done with care, at least to give
> potential users a way to chose which tool to use (really, nobody want to
> go use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
> to pick the right tool. It's a great list, but not a guide).