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.
