Michael Haggerty 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 case of git-svn, what
Michael Haggerty 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 "multimail" part in
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 th
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 mu
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
This is the third iteration of submitting git-multimail to Git. The
first pass [1] was a modest trial balloon, proposing to add a new
script to live alongside post-receive-email. Following feedback [2]
from the mailing list, I decided to make the script a full replacement
for post-receive-email (
6 matches
Mail list logo
