On Tue, Jun 10, 2014 at 09:52:17PM +1000, Stephen Rothwell wrote: > Hi Michael, > > On Tue, 10 Jun 2014 12:42:54 +0300 "Michael S. Tsirkin" <m...@redhat.com> > wrote: > > > > So I see two options: > > - I go ahead with my changes and you with yours and let Linus resolve > > the conflict. This means bisect build will be broken since the > > breakage will likely not be noticed until after the merge. > > Well, since the resolution is known, the one who submits their tree > later should tell Linus (as suggested by Nicholas). That is part of > the point of the linux-next tree ... and therefore there would be no > bisect problem. > > > > Stephen (CC'ed) has included a fix in today's linux-next for the merge > > > conflict here: > > > > > > https://lkml.org/lkml/2014/6/10/3 > > > > > > Please confirm, as it will be a pointer to Linus within the > > > target-pending/for-next PULL request. > > > > Yes but this does mean people trying to bisect will > > hit build breakages, not nice. > > Not necessarily. > > -- > Cheers, > Stephen Rothwell s...@canb.auug.org.au
I don't see how that's possible. Here's a point you might have missed. Nicholas's patch isn't just introducing a merge conflict. It is also buggy. Replacing bit access with has_feature silently fixes the bug. So if we want to avoid bisect breakage target tree will have to be rebased. And if doing that anyway, I don't see any reason not to merge everything through the vhost tree, esp since I already put the patches there. Less work for everyone involved. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
