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:
>> I could add a 
>> bisectability test but that would take a long time to run...
>>     
>
> Testing that each commit builds could be easily automated and quick to
> run. I try to do that before sending a series.
>   

It's certainly doable.  I used to do that as part of my regular process.

>> Alternatively, cooperating among each other to stagger submissions could 
>> help.
>>     
>
> Given the lag between submission and pushing, waiting until the first
> series is pushed probably isn't what we want.
>
> One way I tried solving this before was pulling conflicting patches into
> my tree, re-basing on top of them and then asking you to pull from my
> tree, but that was ignored.
>   

My process is really optimized to avoid losing patches.  It gets 
difficult to maintain this fidelity when dealing with subtree pulls 
unless there's an absolute clear set of rules about what patches can be 
dropped from my normal process.

Subtree pulls have worked great for linux-user because I can drop 
linux-user patches very easily and they never touch anything else.   
Riku also batches linux-user patches on the mailing list which is 
helpful when dealing with subtrees.

As we get better at modularity and some of these touch everything series 
slow down, I think we'll be able to more sanely do subtree pulls.

> I'd have been happy to re-base my series on-top of Gerd's and re-send to
> the list, but I fear you might then have tried to apply my series first
> and then dropped it. Also, I hate spamming the list with large series of
> patches that have only trivially been changed.
>
> How about a simple "I've merged Gerd's into staging, yours conflicts,
> please re-base" on-list? Then I could reply with "Cool, re-base pushed
> to vnet-hdr.v2 in my tree" and you could merge that?
>   

I do this for non-trivial rebases.  It would slow things down 
considerably to do this for everything because as I've said before, 
everything conflicts in some way.  It offers little value to the process 
too.  This was a simple conflict resolution that a trained monkey would 
have been capable of resolving :-)

The big problem is squashing the commits.  It gets challenging because 
it requires every change to be an individual commit and then it often 
takes a lot of manual tinkering to find the right commits to squash 
with.  Using git branch merging would really simplify my life here and 
it's something I've been considering for some time now.

It also helps with review because it demonstrates exactly what I did to 
resolve the conflict.

> Personally, I prefer a linear history but this implies re-basing series.
> A conflicting re-base should be usually be done by the submitter,
> though.
>
> However, if you are to resolve a conflict, it probably should be done as
> a merge commit rather than as a re-base.
>   

Yeah, I've been leaning toward something like this for a while and I 
think I might take a stab at it.  We'll lose a linear history anyway 
once we start using sub trees more so it's not a huge loss.

Regards,

Anthony Liguori