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

[Anthony Liguori <aliguori@us.ibm.com>]

Avi Kivity wrote:
> Why?  When you detect the conflict, ask the unlucky second to rebase 
> (on top of some git branch).  The rebased series doesn't need a 
> re-review unless the submitter says he needed to rework it significantly.
>
> (IOW, the submitter's rebase doesn't need more review than your 
> conflict resolution)

The rebasing is really trivial in most circumstances.  It's akin to do a 
merge conflict resolution after a git pull.

My mistake here was not in how I handled the conflict resolution but in 
how I folded those commits back into the tree.

Basically, the workflow goes like this:

1) apply series
2) resolve conflicts applying series*
3) build
4) when build fails, resolve conflicts by adding new commits*
5) rebase and squash new commits into appropriate old commits

The alternative workflow would be:

1) apply series in branches
2) merge branches, resolving merge conflicts*
3) build
4) when build fails, resolve conflicts by adding new commits
5) squash commits into merge resolution commit

The second workflow eliminates the possibilities of errors in step 5.  
If you look at the patch rates on the mailing list, it would be pretty 
difficult to pick a series, then asking everyone else to resubmit after 
that series is committed.  The last thing we need is more submissions of 
the same series on the mailing list.  We're already practically flooded 
with patches.

[*] if at any point in time this is non-trivial, push back to submitter

-- 
Regards,

Anthony Liguori