[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