Re: [PATCH] git-multimail: update to version 1.0.0

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 9, 2014, 16:01 UTC
Message-ID: <53456EC8.7090109@alum.mit.edu>
In-Reply-To: <xmqqd2gtm0id.fsf@gitster.dls.corp.google.com>

On 04/07/2014 08:56 PM, Junio C Hamano wrote:

Show 24 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> ...
>> Contributions-by: Raphaël Hertzog <hertzog@debian.org>
>> Contributions-by: Eric Berberich <eric.berberich@gmail.com>
>> Contributions-by: Michiel Holtkamp <git@elfstone.nl>
>> Contributions-by: Malte Swart <mswart@devtation.de>
>> Signed-off-by: Michael Haggerty <mhagger@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.

Show 11 quoted lines

> 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 repo [1]:

Show 6 quoted lines

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

Michael

[1] http://article.gmane.org/gmane.comp.version-control.git/226644

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/