From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3BQz-0000ly-R6 for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:31:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3BQv-0000iL-CT for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:31:41 -0400 Received: from [199.232.76.173] (port=35133 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3BQu-0000i5-Tn for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:31:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48591) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3BQu-0006yM-FU for qemu-devel@nongnu.org; Wed, 28 Oct 2009 12:31:36 -0400 Subject: Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2] Add virtio-net/tap support for partial csums and GSO] From: Mark McLoughlin In-Reply-To: <4AE862B4.1040605@codemonkey.ws> References: <1256229830-28066-1-git-send-email-markmc@redhat.com> <1256740226.5105.59.camel@blaa> <4AE862B4.1040605@codemonkey.ws> Content-Type: text/plain Date: Wed, 28 Oct 2009 16:29:34 +0000 Message-Id: <1256747374.5105.82.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Gerd Hoffmann On Wed, 2009-10-28 at 10:26 -0500, Anthony Liguori wrote: > 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. Ah, okay; both series applied fine, but the result didn't build, so you fixed up as a separate commit and then squashed that back into Gerd's series rather than mine. Makes sense now. > I could add a > bisectability test but that would take a long time to run... Testing that each commit builds could be easily automated and quick to run. I try to do that before sending a series. > > 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. Okay. A "Thanks, applied to staging" reply on-list could help trigger the submitter into action. > Alternatively, cooperating among each other to stagger submissions could > help. Given the lag between submission and pushing, waiting until the first series is pushed probably isn't what we want. One way I tried solving this before was pulling conflicting patches into my tree, re-basing on top of them and then asking you to pull from my tree, but that was ignored. I'd have been happy to re-base my series on-top of Gerd's and re-send to the list, but I fear you might then have tried to apply my series first and then dropped it. Also, I hate spamming the list with large series of patches that have only trivially been changed. How about a simple "I've merged Gerd's into staging, yours conflicts, please re-base" on-list? Then I could reply with "Cool, re-base pushed to vnet-hdr.v2 in my tree" and you could merge that? > > 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. Personally, I prefer a linear history but this implies re-basing series. A conflicting re-base should be usually be done by the submitter, though. However, if you are to resolve a conflict, it probably should be done as a merge commit rather than as a re-base. Cheers, Mark.