From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PULL REQUEST] Please pull rdma.git Date: Sun, 24 Jan 2016 17:05:16 -0800 Message-ID: References: <56A2727B.8040809@redhat.com> <56A30910.9010002@redhat.com> <56A3A777.3@redhat.com> <56A3FE6F.4000800@redhat.com> <56A42829.90401@redhat.com> <56A4F986.5070604@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Or Gerlitz Cc: Doug Ledford , David Miller , linux-rdma , Saeed Mahameed , Achiad Shochat , Matan Barak , Alaa Hleihel , Leon Romanovsky , Haggai Eran , Stephen Rothwell List-Id: linux-rdma@vger.kernel.org On Sun, Jan 24, 2016 at 2:13 PM, Or Gerlitz wrote: > > That's news to me. When such things happen and caught by Stephen, we > are getting an email saying something like > > "Today's linux-next merge of the infiniband tree got a conflict > between commit X from net-next tree and commit Y from the infiniband > tree. I fixed it up (see below) and can carry the fix as necessary (no > action is required)." So that's purely about linux-next, and Stephen carrying the merge around there. He's informing you that he has resolved it in linux-next, and you now should know about the issue, and that he won't inform you again, because it's resolved in linux-next (sometimes - very seldom - the clashes get so bad that he just throws out one tree as unresolvable, and then that tree needs to actually work on getting it resolved in linux-next). >> In 99% of all conflicts, the answer is "it's a trivial conflict, both >> sides did the rigth thing, I'm just fixing things up". > > Would it be correct to phrase the points you are trying to make in > this email as: > > If the conflict doesn't fall into a category of being a trivial one, > were both sides did the right thing and someone only has to fix things > up to co-exist -- something is wrong, and the conflict should be > resolved by a per-merge fix to at least one of the patches So it's not entirely about the "trivial" part. Sometimes we have complicated merges, simply because two different people did very different things, and they clashed. But of those two people had a good _reason_ to do different things, and they were fundamentally independent things to do, then even a non-trivial merge migth still be about everybody doing the right thing, and it just happened to clash. Unfortunate, but it can happen. For example, maybe Al Viro did some VFS re-organization that impacted individual filesystems, and then one of the filesystem maintainers did some independent changes for one of the filesystems that just happened to clash. That would still be "everything is fine, we were just slightly unlucky". But when there are two groups in the same company, working on the _same_ driver, then those two groups need to talk. When they clash, it's not "we were just slightly unlucky, working on different things, and normally these things don't interact that way". This is not a matter of two independent groups working on independent things that just have overlap. You're working on the same f*cking driver, doing variations of the same f*cking thing, for chrissake. So talk to each other. We had the same thing happen with the NETDEV_CHANGEUPPER thing from Mellanox. Again, it wasn't two different groups working on two different things that just happened to get a clash. No, it was two different groups inside of Mellanox working on the exact same thing, inside the same company, and they just did the same thing (slightly differently) without ever talking to each other, and sent it out to two different maintainers. See the difference? A _good_ merge conflict is when two groups work on entirely different things and they just happen to have some unfortunate overlap. A bad conflict is when two groups work on the same exact thing and didn't talk it over. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html