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

2013-04-21 Thread Jonathan Nieder
Hi, Michael Haggerty wrote: This series consists of a single patch that adds a directory contrib/hooks/git-multimail/ containing five files, described in the patch's commit message. Yay! I look forward to seeing it. [...] The first of these commits

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

2013-04-21 Thread Junio C Hamano
Jonathan Nieder jrnie...@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 ;-)

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

2013-04-21 Thread Michael Haggerty
On 04/21/2013 08:44 PM, Junio C Hamano wrote: Jonathan Nieder jrnie...@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

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

2013-04-21 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: That seems very workable. That is pretty much it. What is your preference regarding the history to date? The only thing I deeply care about is that initial and subsequent git pull I'll do from you [*1*] will pull in commits that touch only the

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

2013-04-21 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: * 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?) I think I missed this part, but in the