Hi all.
The main point of this series is to teach git to encode my name
correctly, see patch 4, so that the decoded version is actually
my name, so that send-email does not insist on adding a wrong
superfluous From: line to the mail body.
But as always, you notice some other things going wrong. Here,
patches 1 and 2 make the wrapping of header lines more correct,
i. e., neither too early nor too late.
Patch 3 does some refactoring, which is too unrelated to be included
in patch 4 itself.
Patch 5 points out further problems, but leaves the actual fixing
to someone else.
The series is currently based on the maint branch, but it applies
to the others as well.
During the creation of this series, I came across the strbuf
wrapping functions, and I wonder if there is an off-by-one issue.
Consider the following excerpt from t4202:
cat > expect << EOF
This is
the sixth
commit.
This is
the fifth
commit.
EOF
test_expect_success 'format %w(12,1,2)' '
git log -2 --format="%w(12,1,2)This is the %s commit." > actual &&
test_cmp expect actual
'
So this sets a maximum width of 12 characters. Is that 12 character limit
supposed to include the final newline, or not? Because the test above and
my series are only correct if the final newline is included, i. e., at most
eleven visible characters.
If this should mean at most 12 visible characters instead, then the output
should look like this:
This is the
sixth
commit.
This is the
fifth
commit.
(In that case, I would repost an updated version of this series.)
Regards
Jan
Jan H. Schönherr (5):
format-patch: do not wrap non-rfc2047 headers too early
format-patch: do not wrap rfc2047 encoded headers too late
format-patch: introduce helper function last_line_length()
format-patch: fix rfc2047 address encoding with respect to rfc822
specials
format-patch: tests: check rfc822+rfc2047 in to+cc headers
pretty.c| 121 ++
t/t4014-format-patch.sh | 227 ++--
2 Dateien geändert, 229 Zeilen hinzugefügt(+), 119 Zeilen entfernt(-)
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html