Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 21, 2013, 20:02 UTC
Message-ID: <517445E5.3080304@alum.mit.edu>
In-Reply-To: <7vhaizu3j5.fsf@alter.siamese.dyndns.org>

On 04/21/2013 08:44 PM, Junio C Hamano wrote:

Show 10 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> writes:
> 
>> My personal preference is that patches come on the git list, are
>> reviewed here, and then go to your fork of the Git project that Junio
>> can periodically pull from at your request (like git-svn).  But of
>> course this is up to you, too.
> 
> And also me ;-)
> 
> Yes, I very much prefer the way how git-svn is managed.

Let me see if I understand what that means:

* I maintain my own Git clone

* Patches to git-multimail would go to the Git mailing list like patches
to other patches to the Git project, but I would be the one to git-am
them, monitor discussion, help with review, etc.  I would presumably
apply the patches near your master (or near maint when necessary).

* When I think a batch of patches is ready, I merge them to my master
and publish my master somewhere.  (Or is it better I publish the feature
branch and leave it to you to merge directly to your master?)  Then I
send a merge request to you and the Git mailing list with the URL and
SHA-1 of the branch that I would like you to merge.

That seems very workable.

What is your preference regarding the history to date?

Michael

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