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

[Mark McLoughlin]

On Wed, 2009-10-28 at 10:26 -0500, Anthony Liguori wrote:
> 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.

Ah, okay; both series applied fine, but the result didn't build, so you
fixed up as a separate commit and then squashed that back into Gerd's
series rather than mine. Makes sense now.

> 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.

> > 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.

Okay. A "Thanks, applied to staging" reply on-list could help trigger
the submitter into action.

> 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.

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?

> > 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.

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.

Cheers,
Mark.