[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2] Add

From: Avi Kivity
Subject: Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2] Add virtio-net/tap support for partial csums and GSO]
Date: Thu, 29 Oct 2009 10:18:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

On 10/28/2009 06:36 PM, Anthony Liguori wrote:
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.

Well, if it's just an error I don't see a need for a change in procedure. FWIW, I do a lot of rebasing too (for different reasons - not introduce a bug and its fix in the same pull, cross-arch compile fixes, fold reverts and incremental fixes). To ensure I don't screw things up, I always compare the result of the rebase with the original (git diff should show nothing), and build-test every revision on every arch. With ccache it's fairly reasonable, even on s390.

Do not meddle in the internals of kernels, for they are subtle and quick to 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]