Joe Perches, 01.07.2009:
> using
> git format-patch --thread=shallow -o <foo>
> and
> git send-email --no-thread --no-chain-reply-to <foo>
I guess you meant --thread here.
> duplicates the headers
>
> In-Reply-To:
> References:
I noticed the duplicated headers when fixing two bugs some weeks ago. I
guess to get rid of the duplicated headers, you have to parse the mail
that format-patch produces, since you don't have a clue, what
format-patch did. I'm not sure if it's worth it, if the duplicated
headers don't harm the email standard. It only complicates the tool.
> Signed-off-by: Joe Perches <joe@xxxxxxxxxxx>
> ---
> git-send-email.perl | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 8ce6f1f..1b9b27e 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1151,7 +1151,8 @@ foreach my $t (@files) {
>
> # set up for the next message
> if ($thread && $message_was_sent &&
> - ($chain_reply_to || !defined $reply_to || length($reply_to) == 0)) {
> + ($chain_reply_to &&
> + (!defined $reply_to || length($reply_to) == 0))) {
> $reply_to = $message_id;
> if (length $references > 0) {
> $references .= "\n $message_id";
This part of git-send-email seems to be prone for errors, blame it and
you will see in the latest commits.
You should run at least the test from the test suite for the particular
command you change. Test 49 (threading but no chain-reply-to) from t9001
now fails.
That means, this will fail now (covered by test 49):
git format-patch -o <foo>
git send-email --thread --no-chain-reply-to <foo>
and also this (not covered by any test, maybe we should add one):
git format-patch -o <foo>
git send-email --thread --chain-reply-to <foo>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html