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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 17 Oct 2019 17:06:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Will Deacon <will@...nel.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 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.

In general, people who aren't doing fancy things with git should never
get to the "multiple merge bases" situation, and then the regular pull
request logic works fine.

And people likme you who are doing multiple branches and know what
they are doing are also able to them handle the "uhhuh, I need to do a
merge to get a good diffstat" situation.

            Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ