Re: why does git-send-email unwrap headers?

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jun 2, 2021, 18:04 UTC
Message-ID: <20210602180443.girwpb2ovwczywmk@nitro.local>
In-Reply-To: <YLe3k1CYMhv9LEeh@nand.local>

On Wed, Jun 02, 2021 at 12:53:39PM -0400, Taylor Blau wrote:

Show 9 quoted lines

> On Wed, Jun 02, 2021 at 11:34:41AM -0400, Konstantin Ryabitsev wrote:
> > While it's not *wrong* (the 78-character limit is from a very old RFC), I'm
> > curious if this is intentional or just an oversight.
> 
> My guess is that this dates back to 5012699d98 (send-email: handle
> multiple Cc addresses when reading mbox message, 2009-02-14), which
> unfolds all multi-line headers, probably so that parsing the header can
> be done line-wise without having to keep track of whether you are
> parsing a continuation line or not.

I think you're right, but I believe simply removing the two lines that do the actual unwrapping will fix this without causing any side-effects.

I.e. when parsing headers, don't "unwrap" them but merely concatenate all header lines to the proper header. Address parsing routines should still properly handle this situation, though it's less clear to me if something else may be affected by this change.

CC'ing Ævar Arnfjörð Bjarmason, who I think is the person most poking at git-send-email lately.

-- >8 --

diff --git a/git-send-email.perl b/git-send-email.perl
index 25be2ebd2a..4c79122f78 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1654,8 +1654,6 @@ sub process_file {
        while(<$fh>) {
                last if /^\s*$/;
                if (/^\s+\S/ and @header) {
-                   chomp($header[$#header]);
-                   s/^\s+/ /;
                        $header[$#header] .= $_;
            } else {
                        push(@header, $_);

-- >8 --

-K