linux-kernel - Re: [GIT PULL] arm64: Fixes for -rc4

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: <20191018174153.slpmkvsz45hb6cts@willie-the-truck>
Date:   Fri, 18 Oct 2019 18:41:56 +0100
From:   Will Deacon <will@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM Kernel Mailing List 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [GIT PULL] arm64: Fixes for -rc4

On Thu, Oct 17, 2019 at 05:06:54PM -0700, Linus Torvalds wrote:
> On Thu, Oct 17, 2019 at 4:43 PM Will Deacon <will@...nel.org> wrote:
> >
> > Note that the workaround code ended up being based on -rc2, so I had a
> > bit of a faff trying to generate the right diffstat for this pull request
> > after merging that branch into our fixes branch based on -rc1. In the end
> > I had to emulate the pull locally because I couldn't figure out how to
> > drive request-pull correctly despite the shortlog being correct. I'd love
> > to know what I should've done instead.
> 
> You did the right thing.
> 
> When there are multiple merge bases, a regular "git diff" doesn't work
> since it's fundamentally about two end-points (well, it _can_ work
> almost by mistake, but doesn't work in the general case). So the only
> way to get a "proper" diff is to do a merge and then diff the result.
> 
> That said, I also accept the output of "git diff" which will then have
> a lot of noise from all the _other_ work done between the two merge
> bases. I can figure out what happened, and do my own two-endpoint diff
> and see what happened, and still se that "yes, that's what the pull
> request meant, and that's why the diffstat is garbage".
> 
> What you did is the "good quality" pull request, though.

Thanks, that's helpful to know for next time. I guess I'm most surprised by
the discrepancy between the shortlog and the diffstat, whereas I intuitively
expected them to be generated in the same way.

Will