qemu-devel
[Top][All Lists]
Advanced

[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: Anthony Liguori
Subject: Re: Handling merge conflicts [was Re: [Qemu-devel] [PATCH 00/19 v2] Add virtio-net/tap support for partial csums and GSO]
Date: Wed, 28 Oct 2009 10:26:44 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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. I could add a bisectability test but that would take a long time to run...

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.

Alternatively, cooperating among each other to stagger submissions could help.

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.

Regards,

Anthony Liguori




reply via email to

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