Matthieu Moy <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
