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
