From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3AXP-0004WG-Kt for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:34:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3AXK-0004La-4Y for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:34:14 -0400 Received: from [199.232.76.173] (port=42741 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3AXJ-0004LE-Nw for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:34:09 -0400 Received: from ey-out-1920.google.com ([74.125.78.149]:14209) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3AQG-0003ad-PM for qemu-devel@nongnu.org; Wed, 28 Oct 2009 11:26:53 -0400 Received: by ey-out-1920.google.com with SMTP id 3so765379eyh.14 for ; Wed, 28 Oct 2009 08:26:51 -0700 (PDT) Message-ID: <4AE862B4.1040605@codemonkey.ws> Date: Wed, 28 Oct 2009 10:26:44 -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> In-Reply-To: <1256740226.5105.59.camel@blaa> 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: Mark McLoughlin Cc: Anthony Liguori , qemu-devel@nongnu.org, Gerd Hoffmann Mark McLoughlin wrote: > Hi Anthony, > Thanks for merging this stuff ... > > In the process of merging it all into qemu-kvm, I noticed a couple of > problems: > > 1) bb6e63644 lacked the change to add the type code to > qemu_new_vlan_client() so that and the subsequent 14 commits are > unbuildable > > 2) 93db6685 references NET_CLIENT_TYPE_NIC and the receive_raw but > these aren't added until bb6e636443 and 70783b9c, so that's 117 > unbuildable commits > > Neither of these problems existed in the patches Gerd and I posted, so > presumably they came about by trying to merge the two patch sets? > It means I squashed the resolutions incorrectly. I could add a bisectability test but that would take a long time to run... > How can we avoid this happening in future? What process could we have > used to avoid it? > There are a few ways. This was all sitting in staging for quite some time so poking at staging proactively could have helped. Alternatively, cooperating among each other to stagger submissions could help. > Should either Gerd or I have merged the others' changes into our tree > and asked you to pull? Should you just refuse conflicts and ask us to > re-post? Or ...? > Everything conflicts. This isn't obvious because 99% of the time, I resolve it without any trouble. If the merge isn't trivially resolvable, then I do push back on the submitter. In this case, it was easily resolvable but I just squashed wrong. The best way to address this from a git perspective would be for change the way I merge things such that I merge series into separate branches against master, then merge the branches together. The result would be much more obvious merges and no chance of something like this happening. On the flip side, history would get much worse to read. If people feel strongly one way or another, I'm happy to adjust. This was just a mistake on my part. Regards, Anthony Liguori