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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/07/2014 08:56 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> 
>> ...
>> Contributions-by: Raphaël Hertzog <hertzog@xxxxxxxxxx>
>> Contributions-by: Eric Berberich <eric.berberich@xxxxxxxxx>
>> Contributions-by: Michiel Holtkamp <git@xxxxxxxxxxx>
>> Contributions-by: Malte Swart <mswart@xxxxxxxxxxxx>
>> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
>> ---
>> 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
repo [1]:

> 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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]