Re: [PATCH] sequencer: support folding in rfc2822 footer

On Tue, Sep 06, 2016 at 04:30:24PM -0700, Jonathan Tan wrote:

On 09/06/2016 03:08 PM, Jonathan Tan wrote:

quoted

On 09/02/2016 07:23 PM, Junio C Hamano wrote:

quoted

A slightly related tangent.  An unconditionally good change you
could make is to allow folding of in-body headers.  I.e. you can
have e.g.

    -- >8 --
    Subject: [PATCH] sequencer: support in-body headers that are
         folded according to RFC2822 rules

    The first paragraph after the above long title begins
    here...

in the body of the msssage, and I _think_ we do not fold it properly
when applying such a patch.  We should, as that is something that
appears in format-patch output (i.e. something Git itself produces,
unlike the folded "footer").

OK, I'll take a look at this.

It turns out that Git seems to already do this, at least for Subject.

Right, because "Subject" is actually a real RFC 2822 header in the
generated email message. Not only do we expect things like mail readers
to handle this, but we _have_ to wrap at a certain point to meet the
standard[1].

I don't think any part of Git ever shunts "Subject" to an in-body
header, though I'd guess people do it manually all the time. 

$ git format-patch HEAD^
0001-this-is-a-very-long-subject-to-test-line-wrapping-th.patch
$ cat 0001-this-is-a-very-long-subject-to-test-line-wrapping-th.patch
<snip>
Subject: [PATCH] this is a very long subject to test line wrapping this is a
 very long subject to test line wrapping
<snip>

So the interesting bit is what happens with:

  git checkout master^
  git am 0001-*

and with:

  perl -lpe '
    # Bump subject down to in-body header.
    if (/^Subject:/) {
	print "Subject: real subject";
	print "";
    }
  ' 0001-* >patch
  git checkout master^
  git am patch

It looks like we get the first one right, but not the second.

-Peff

[1] A careful reader may note that arbitrarily-long body lines,
    including in-body headers and footers, may _also_ run afoul of
    the body line-length limits. The "right" solution there is
    probably quoted-printable, but it's ugly enough that I wouldn't do
    so unless we see a real-world case where the line lengths are a
    problem.