[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