[GIT PULL] RISC-V Devicetrees fix for Sophgo/SG2042 v6.8-rc1
Chen Wang
unicorn_wang at outlook.com
Fri Jan 26 04:31:09 PST 2024
On 2024/1/26 15:10, Arnd Bergmann wrote:
> On Fri, Jan 26, 2024, at 08:06, Chen Wang wrote:
>> On 2024/1/26 14:11, Arnd Bergmann wrote:
>> [......]
>>> The tag description is what gets turned into the merge commit
>>> when I pull it, so it needs to be something that makes sense
>>> for the long-term git history as well as for me to understand
>>> why I need to pull it.
>>>
>>> For a normal branch, that would mainly mean that you should
>>> give a summary of the branch contents. In this case, I see you
>>> have only one patch, so it's probably easier to send that
>>> patch to soc at kernel.org individually, with the same cc list.
>> I have one question about your mentiond "send that patch to
>> soc at kernel.org individiually ...". If I sent it as a patch, where
>> should I add the explanation of what I explained in this GIT PULL about
>> the omission. After all, the content of this explanation is not part of
>> the commit of that patch.
>>
>> Should I send this patch email and then reply it, and then explain in
>> the reply email?
> There are two common ways of doing it:
>
> a) You can add extra information below the '---' line in your
> patch, next to the diffstat. This text will get dropped during
> 'git am' when I pick it up but is available when I look at
> the email.
>
> b) You can send the patches as a series using 'git format-patch
> --cover letter' and 'git send-email'. In this case, the cover
> letter will be numbered as '[PATCH 0/1]' and allow you to
> add the same kind of description that would go into a pull
> request but won't become a merge commit.
>
> Arnd
Hi, Arnd,
I have re-sent that patch to soc at kernel.org. Will it be merged in master
in 6.8-rc2?
Thanks,
Chen
More information about the linux-riscv
mailing list