Matthieu Moy <matthieu....@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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html