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

From: Josh Triplett <josh@joshtriplett.org>
Date: Aug 5, 2016, 19:21 UTC
Message-ID: <20160805192108.oe3yd5eyu4jopvwn@x>
In-Reply-To: <CAGZ79ka5OknKYo_CgBpB16EQjwU5B35yNFWx569K-LPmHuSqWA@mail.gmail.com>

On Mon, Sep 17, 2001 at 10:00:00AM +0000, Stefan Beller wrote:

Show 7 quoted lines

> But both send-email as well as mail-patch-series as well as git-series
> are all about the *sending* part. Not about the back and forth part, i.e.
> these don't deal with: "here is a fixup on top". And by that I mean
> receiving mails and applying them. git-am is there as a front-end
> once you obtained the mail, but from what I get, your original problem
> is to get up to date with the latest state, that is either in pu or a proposed
> fixup mail on top of your series?

git-series, at least, is intended to handle the back-and-forth: if you actually publish the series and not just the final result, someone could pull the series, make a (non-fast-forwarding) change to that, make a new series commit, and publish their modified version of your series. You could then incorporate that change. One of the use cases I developed it for was collaborative development of a patch series.

(That workflow still needs a lot more tool assistance to become fully usable, not least of which to assist with the process of merging changes to the series. Working on that.)