From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3BWG-00046N-Kc for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:37:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3BWC-00041Y-Dc for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:37:08 -0400 Received: from [199.232.76.173] (port=55319 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3BWC-00041G-2e for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:37:04 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:38123) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N3BWB-00086K-ML for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:37:03 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9SGW9v2023769 for ; Wed, 28 Oct 2009 10:32:09 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9SGae3v171688 for ; Wed, 28 Oct 2009 10:36:47 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9SAZYnO025458 for ; Wed, 28 Oct 2009 04:35:34 -0600 Message-ID: <4AE87313.5030904@us.ibm.com> Date: Wed, 28 Oct 2009 11:36:35 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2] Add virtio-net/tap support for partial csums and GSO] References: <1256229830-28066-1-git-send-email-markmc@redhat.com> <1256740226.5105.59.camel@blaa> <4AE85BC6.1080508@redhat.com> <4AE86325.5090000@codemonkey.ws> <4AE87031.5070309@redhat.com> In-Reply-To: <4AE87031.5070309@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Mark McLoughlin , Gerd Hoffmann , qemu-devel@nongnu.org Avi Kivity wrote: > Why? When you detect the conflict, ask the unlucky second to rebase > (on top of some git branch). The rebased series doesn't need a > re-review unless the submitter says he needed to rework it significantly. > > (IOW, the submitter's rebase doesn't need more review than your > conflict resolution) The rebasing is really trivial in most circumstances. It's akin to do a merge conflict resolution after a git pull. My mistake here was not in how I handled the conflict resolution but in how I folded those commits back into the tree. Basically, the workflow goes like this: 1) apply series 2) resolve conflicts applying series* 3) build 4) when build fails, resolve conflicts by adding new commits* 5) rebase and squash new commits into appropriate old commits The alternative workflow would be: 1) apply series in branches 2) merge branches, resolving merge conflicts* 3) build 4) when build fails, resolve conflicts by adding new commits 5) squash commits into merge resolution commit The second workflow eliminates the possibilities of errors in step 5. If you look at the patch rates on the mailing list, it would be pretty difficult to pick a series, then asking everyone else to resubmit after that series is committed. The last thing we need is more submissions of the same series on the mailing list. We're already practically flooded with patches. [*] if at any point in time this is non-trivial, push back to submitter -- Regards, Anthony Liguori