Re: CR position changed in exported patch file subject section

From: Jeff King <peff@peff.net>
Date: Feb 26, 2024, 07:02 UTC
Message-ID: <20240226070255.GA780982@coredump.intra.peff.net>
In-Reply-To: <IA0PR12MB822712F1B3E5205711493D55EF5A2@IA0PR12MB8227.namprd12.prod.outlook.com>

On Mon, Feb 26, 2024 at 05:53:19AM +0000, Chen, Boyang wrote:

Show 14 quoted lines

> 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:

Show 5 quoted lines

> 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