Matthieu Moy <> 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

 (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 (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

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
> 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
More majordomo info at

Reply via email to