On 04/07/2014 08:56 PM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>> Contributions-by: Raphaël Hertzog <hert...@debian.org>
>> Contributions-by: Eric Berberich <eric.berber...@gmail.com>
>> Contributions-by: Michiel Holtkamp <g...@elfstone.nl>
>> Contributions-by: Malte Swart <msw...@devtation.de>
>> Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
>> Junio, how would you like other people's contributions to be recorded
>> within the Git project? I have listed them above as
>> "Contributions-by". All of these people have signed off on their
>> contributions (recorded in my GitHub repo). So should I also/instead
>> add "Signed-off-by" for those people?
> Either is fine, as long as somewhere in that directory:
> - we make it clear that the copy we have in contrib/ is merely for
> "batteries included" convenience;
> - we refer to the canonical source that is your repository;
> - we tell readers to go there to get the authoritative and up to
> date copy, as what we have in contrib/ is possibly stale.
This information is already present in README.Git, though it doesn't say
explicitly that the copy within the Git source tree might be stale. I
can add that if you like.
> In the longer term, I have a feeling that we may be better off to
> make the "git core" tree not be the "batteris included" convenience
> tree, though. In the early days, Linus's rationale for including
> "gitk" held true: having tools that are not quite core is a good way
> to get people (especially those without C background) involved in
> the still-small project in its infancy to help nurture the developer
> community. The same reasoning stood behind the merging of "gitweb".
> We already are beyond that stage, and good tools like iMerge and
> multimail that can stand on its own may be better off flourishing
> outside "git core" tree, still within the same developer community.
I was going by what you said when multimail was originally added to your
> 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 multimail tool can be in the second category. It helps use of
> Git more than it is helped by using Git.
Tell me if/when you want to transition to omitting git-multimail (and
presumably post-receive-email and maybe others) from the Git source
tree. I suppose in that case we would replace the scripts with pointers
to where they can be obtained.
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