Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

From: Jeff King <peff@peff.net>
Date: Aug 3, 2016, 16:34 UTC
Message-ID: <20160803163449.iwjv4youmsf6okme@sigill.intra.peff.net>
In-Reply-To: <CAPc5daXJzMsJf5K84XBFuQ5=q_OwtYUW2FikZ2QsZWk8fa9jgg@mail.gmail.com>

On Wed, Aug 03, 2016 at 08:33:12AM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> On Wed, Aug 3, 2016 at 4:59 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > I disagree, however, with the suggestion to sift through your `pu` branch
> > and to somehow replace local branches with the commits found there.
> 
> To be more in line with the "e-mailed patch" workflow, I think what I should
> do is to send the version I queued with fixups back to the list as follow-up.
> Just like reviewers review, the maintainer reviews and queues, the original
> author should be able to work in the same workflow, i.e. reading and applying
> an improved version of the patch from her mailbox.

Leaving aside Dscho's questions of whether pulling patches from email is convenient for most submitters (it certainly is for me, but I recognize that it is not for many), I would much rather see incremental fixup patches from you than whole "here's what I queued" responses.

The reason is that your fixups may not be the only ones needed. There may be others on the list that come before or after, and I may even have already made fixes locally for "v2" that haven't been on the list. If I haven't made any changes yet, I can throw out my topic, start with what you queued, and then apply other changes incrementally. But if I have, then I need to convert yours to a diff, which requires checking out the same base, applying yours, and running diff. Much easier to get the diff in the first place. :)

That only covers changes to the code, though. It does not help with fixups to commit messages. It would be neat to have a microformat for specifying and applying patches to commit messages.

-Peff