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]

Message-ID: <20180817212722.GB28777@ziepe.ca>
Date:   Fri, 17 Aug 2018 15:27:22 -0600
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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 01:27:02PM -0700, Linus Torvalds wrote:
> 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.

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

Jason