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