linux-kernel - Re: [GIT PULL] Please pull RDMA subsystem changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Aug 2018 13:27:02 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jason Gunthorpe <jgg@...lanox.com>
Cc:     Doug Ledford <dledford@...hat.com>,
        linux-rdma <linux-rdma@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Please pull RDMA subsystem changes

On Fri, Aug 17, 2018 at 1:15 PM Jason Gunthorpe <jgg@...lanox.com> 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