CR position changed in exported patch file subject section

CR position changed in exported patch file subject section

[Chen, Boyang]

[AMD Official Use Only - General]

Hi guys,

Recently I faced a question that the CR position in the patch is not in line with the git log.
Below are the steps to reproduce.

touch aaa
git add aaa
git commit -m "Add a file to test, make sure that the message is a bit long but in a single line"

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).

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

---
aaa | 0
1 file changed, 0 insertions(+), 0 deletions(-)


Actually,  we want to keep the commit message format(subject section) in the patch same as the git log output.
I have tried most of arguments of git format-patch and even upgrade the git version.
But no good result is observed.

Could you please help to look at this question? Thanks a lot!

BR
Boyang

RE: CR position changed in exported patch file subject section

[Chen, Boyang]

[AMD Official Use Only - General]

Hi guys,
Pls ignore the first email as there is some format mistake in it and pick this one.
Recently I faced a question that the CR position in the patch is not in line with the git log.
Below are the steps to reproduce.

touch aaa
git add aaa
git commit -m "Add a file to test, make sure that the message is a bit long but in a single line"

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).

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

---
aaa | 0
1 file changed, 0 insertions(+), 0 deletions(-)


Actually,  we want to keep the commit message format(subject section) in the patch same as the git log output.
I have tried most of arguments of git format-patch and even upgrade the git version.
But no good result is observed.

Could you please help to look at this question? Thanks a lot!

BR
Boyang

Re: CR position changed in exported patch file subject section

[Jeff King]

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

RE: CR position changed in exported patch file subject section

[Chen, Boyang]

[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@peff.net>
Sent: Monday, February 26, 2024 3:03 PM
To: Chen, Boyang <Boyang.Chen@amd.com>
Cc: git@vger.kernel.org
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