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] [day] [month] [year] [list]

Message-ID:
 <MA0P287MB28222124EBD67F5B036943EDFE9E2@MA0P287MB2822.INDP287.PROD.OUTLOOK.COM>
Date: Fri, 6 Sep 2024 16:12:26 +0800
From: Chen Wang <unicorn_wang@...look.com>
To: Arnd Bergmann <arnd@...db.de>, 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 2024/9/6 14:54, Arnd Bergmann wrote:
> 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

Thank you Arnd for your careful explaination. I will pay attention to 
these issues later.

Regards,

Chen