Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2] Add virtio-net/tap support for partial csums and GSO]

[Anthony Liguori <anthony@codemonkey.ws>]

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