Michael Haggerty <mhagger@xxxxxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html