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

[Rafael Aquini <aquini@redhat.com>]

On Thu, Jun 25, 2020 at 06:08:24PM -0700, Carlo Arenas wrote:
> 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