Re: [Administrivia] On ruby and contrib/

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> * at the source-code level, a tool in contrib can take advantage of some
> of the Git build/test infrastructure, though I don't know whether they
> currently do.

They do not do much AFAICT. For example, contrib/subtree/t/Makefile is
essentially copy-pasted from Git's equivalent.

But they can do to some extend, for example "make install" in
contrib/mw-to-git/ re-uses Git's Makefile to hardcode the PERL_PATH in
the file, find Git's exec-path & so. I'd love to be able to use
Documentation/Makefile and t/Makefile too for external programs meant to
be used as a Git command.

That does not strictly imply that these commands be maintained within
git.git, as we could imagine:

* 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 also see contrib/ as a "safe" place to live, in that the likeliness
for the project to be abandonned is rather small. Especially for small
pieces of code, it's easy to create a repo and throw the code somewhere
on GitHub, but maintaining it is harder. Take again the example of
post-receive-email, the code was originally written by Andy Parkins, but
the community took over it (Andy's last commit on the script was in
2008). I'm not sure this would have been so easy with a script hosted on
an arbitrary repo.


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

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/