Re: [PATCH] send-email: restore --in-reply-to superseding behavior

From: Rafael Aquini <aquini@redhat.com>
Date: Jun 26, 2020, 13:39 UTC
Message-ID: <20200626133947.GB2235017@optiplex-lnx>
In-Reply-To: <CAPUEspgoDUGUmFqoKkmKDpRzSB5dQNb+PasaPjbPwb04SBz=Ww@mail.gmail.com>

On Thu, Jun 25, 2020 at 06:08:24PM -0700, Carlo Arenas wrote:

Show 10 quoted lines

> a test case in t/t9001-send-email.sh will also help, as I am not sure
> this might be "expected behaviour" as hinted in the man page for
> git-send-email (under --thread):
> 
> "It is up to the user to ensure that no In-Reply-To header already exists
>   exists when git send-email is asked to add it (especially note that
>   git format-patch can be configured to do the threading itself).
>   Failure to do so may not produce the expected result in the
>   recipient's MUA."
>

A quick note: this change does not break that assumption, as well. The "ensure it exists" part means the header must either be in the messages, as populated by format-patch, or it is provided by the --in-reply-to switch option. send-email --thread is not orthogonal, but complementar with --in-reply-to, AFAICS.

The problem we have, right now, is that "send-email --in-reply-to" input gets dropped on the floor if you don't explicitly do "format-patch --no-thread" (or extract a single patch), and this is a behavior regression introduced after v2.17.2

I took a glance in the test-cases, an it seems this is already covered:

test_expect_success $PREREQ 'in-reply-to but no threading' '
        git send-email \
                --dry-run \
                --from="Example <nobody@example.com>" \
                --to=nobody@example.com \
                --in-reply-to="<in-reply-id@example.com>" \
                --no-thread \
                $patches >out &&
        grep "In-Reply-To: <in-reply-id@example.com>" out
'

Cheers, -- Rafael