From: Michael Haggerty Date: Sun, 21 Apr 2013 20:02:45 GMT Subject: Re: [PATCH v3 0/1] git-multimail: a replacement for post-receive-email 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: > Jonathan Nieder 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/