linux-kernel - Re: linux-next: duplicate patches in the sophgo tree

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: <9b83c044-5f22-499e-94a2-1c81f41cb620@app.fastmail.com>
Date: Fri, 06 Sep 2024 06:54:10 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Chen Wang" <unicorn_wang@...look.com>,
 "Stephen Rothwell" <sfr@...b.auug.org.au>,
 "Inochi Amaoto" <inochiama@...look.com>, "Olof Johansson" <olof@...om.net>
Cc: ARM <linux-arm-kernel@...ts.infradead.org>,
 "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
 linux-next <linux-next@...r.kernel.org>
Subject: Re: linux-next: duplicate patches in the sophgo tree

On Fri, Sep 6, 2024, at 03:24, Chen Wang wrote:
> Hi，Stephen,
>
> The arm-soc tree contains these patches is due to I submited a PR to 
> Arnd and he merged this today.
>
> And for the sophgo/for-next branch, it does contains these patches. I 
> created the PR branch(sophgo/riscv-sophgo-dt-for-next) and cherry-picked 
> these patches from sophgo/for-next and submited the PR. I see the 
> commits in arm-soc are the same as that from 
> sophgo/riscv-sophgo-dt-for-next, but they are different against the 
> commit ids from sophgo/for-next due to cherry-pick operation.
>
> So my question is, do we need to make sure commit id the same between PR 
> branch and sophgo/for-next branch?

It certainly makes things easier for everyone if you have the
same commit IDs, yes. Aside from tripping Stephen's sanity checks,
having rebased commits in your tree also means that the branch that
gets tested is different from the one that gets merged.

If you have multiple branches that you want to be in linux-next but
get merged through different upstream trees, your for-next branch
would normally just be a merge of those rather than a cherry-pick.

[Side note: you should also ensure that each of those branches
individually works correctly, i.e. it may add features that only work
when combined with the other branches, but it never introduces
regressions when merged without the other ones.]

      Arnd