[GIT PULL] RISC-V Devicetrees fix for Sophgo/SG2042 v6.8-rc1
Arnd Bergmann
arnd at arndb.de
Thu Jan 25 23:10:30 PST 2024
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
More information about the linux-riscv
mailing list