On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > > We often have merge conflicts with RDMA, how do you prefer to get the > PR? I'm actually not very clear on this part of the process. I generally prefer the non-merged version, but with comments about the conflicts. In fact, the really preferred model is generally to send me a non-merged pull request (say "tags/for-linus") but if the conflicts look even half-way nasty - or simply because you did the merge anyway just to get the proper diffstat because history is complex - mention that you have a merged branch for verification (say "branch/for-linus-merged"). When I get that kind of pull request, I'll just do the merge resolution myself, and after I've done it I'll generally then do git checkout -b test-merge git pull <repoaddress> for-linus-merged and then just compare the end result with my resolution as an extra verification step. I may end up skipping the verification step if everything looks entirely trivial (and really, if you have no real reason for the pre-merged branch, don't bother even mentioning it even if you did it for the diffstat), but in practice whenever somebody does that, I have no reason not to just do that simple extra verification. Most of the time the merges are exactly the same, possibly with whitespace or trivial ordering differences (things like Makefiles and Kconfig files often have add-add conflicts where the ordering really doesn't matter between two config options). And then sometimes it shows that I missed something in my mmerge. And sometimes it shows that I do so many merges that I actually ended up noticing something that the submaintainer didn't. So it can be uninteresting, and when it isn't uninteresting it can go either way, but so far for the people who do this, I've never been in the situation where I was *sorry* for the double merge and extra verification step. Because when mis-merges happen (they are happily pretty rare) they are _so_ annoying and can be so hard to figure out later, that I'd rather spend a bit more time on the merge than have a dodgy one. Linus