Re: [Administrivia] On ruby and contrib/

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 7, 2013, 16:11 UTC
Message-ID: <7vvc5puchl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpq61xr8kpl.fsf@anie.imag.fr>

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

Show 19 quoted lines

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

Show 5 quoted lines

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