Re: [GIT PULL] Please pull RDMA subsystem changes

[Jason Gunthorpe]

On Fri, Aug 17, 2018 at 01:27:02PM -0700, Linus Torvalds wrote:
> 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.

Thanks for the explanation. Doug and I will do this in future.

Jason