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
