Re: [Administrivia] On ruby and contrib/

Matthieu Moy [off-list ref] 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).

quoted

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