On Sat, Jan 10, 2015 at 2:27 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Sat, Jan 10, 2015 at 2:13 PM, Andy Lutomirski <l...@amacapital.net> wrote: >> >> I'll make the same change to my pending entry work, and hopefully we >> can avoid conflicts. > > That's not how conflicts work. > > Either there is no overlap between the changes at all, in which case > it doesn't matter if you then also have Denys' changes in your tree. > > Or you have other changes that change code around Denys' code, in > which case you'll get conflicts whether you have Denys' changes or not > (because two branches will be changing the same area differently, and > so there's a conflict that needs to resolve which side was right). > > So the only way to avoid a conflict is to not touch the same code, or > to touch it *exactly* the same way in all respects. > > Now, while the *conflict* is not something you can't avoid, some > conflicts are easier to resolve than others, and from a conflict > resolution standpoint it can make sense for your branch to include > Denys' changes.
Hmm. What I meant here about avoiding conflicts was more like "with any luck, the timing will work out such that the code conflicts don't end up happening." > > Why? Because if whoever resolves the conflict sees that one branch is > a proper superset of the other branch, than the resolution is a much > more obvious "let's just take everything from one side" edit, rather > than having to pick-and-choose. > > I I do actually agree with you taking the fixes (and maybe you should > *entirely* take ownership of all the entry_64.S changes, so that there > is no "other side" to conflict with at all!). I just wanted to point > out the actual effects from a conflict standpoint. > Egads. As if the vdso isn't bad enough. Mumble mumble maybe I'll agree to maintain this masterpiece of well-engineered asm. --Andy > Linus -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/