[AMD Official Use Only - General] Hi Peff, Thanks for your clarification. The commit message is just a single line, but the subject section is splinted into two lines as the line characters number is more than 78. This is in line with the design. The content you read doesn't have this change, maybe it is caused by the outlook content format. perhaps the existing --no-encode-email-headers should be used as a hint that the user prefers easy-to-parse output over strict rfc compliance. ==> I have tried this command, the generated patch subject section is still splinted into two lines. I have wondered if it would be useful to have a --no-wrap-email option. ==> if we add this new option and output the commit message as the way that git log command does, it should be good with usage. Thanks again! BR Boyang -----Original Message----- From: Jeff King <peff@xxxxxxxx> Sent: Monday, February 26, 2024 3:03 PM To: Chen, Boyang <Boyang.Chen@xxxxxxx> Cc: git@xxxxxxxxxxxxxxx Subject: Re: CR position changed in exported patch file subject section Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. On Mon, Feb 26, 2024 at 05:53:19AM +0000, Chen, Boyang wrote: > D:\Source\CustomerRepoTest\Platform1>git log -3 commit > 0c9f8555c55c73fd4e5392c8f8516c389f362d17 (HEAD -> test) > Author: Boyang Chen > Date: Mon Feb 26 11:16:00 2024 +0800 > > Add a file to test, make make sure that the message is a bit long > but in a single line > > We can confirm that the commit message is in a single line in the output of git log command(pls refer to above output). > > And use below command to generate a patch file. > git format-patch -3 --stdout > exported_3.patch > > We can observe that the commit message's CR position is changed in the > exported patch, the subject section is split to two lines(pls refer to > below output). This is expected. The format-patch command is generating an email, and rfc2822 says: Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. But we can make the subject arbitrarily long by using header continuation; the line after the "Subject:" should start with whitespace, which indicates to a parser that it is a continuation of the previous header. You don't show that here: > From 0c9f8555c55c73fd4e5392c8f8516c389f362d17 Mon Sep 17 00:00:00 2001 > From: Boyang Chen > Date: Mon, 26 Feb 2024 11:16:00 +0800 > Subject: [PATCH 3/3] Add a file to test, make make sure that the > message is a bit long but in a single line but I'm not sure if it's really missing, or if the whitespace got munged as you sent it. Assuming it is, then everything is working as designed. That said, I have sometimes been annoyed at this myself, because I want to process the mails with tools that are quite capable of handling long lines (e.g., mutt). And doing hacky processing with perl, etc, becomes harder because you have to actually parse the mail correctly rather than just grepping for "^Subject:". ;) So I have wondered if it would be useful to have a --no-wrap-email option. Or perhaps the existing --no-encode-email-headers should be used as a hint that the user prefers easy-to-parse output over strict rfc compliance. -Peff
