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@xxxxxxxxxxx>" \
--to=nobody@xxxxxxxxxxx \
--in-reply-to="<in-reply-id@xxxxxxxxxxx>" \
--no-thread \
$patches >out &&
grep "In-Reply-To: <in-reply-id@xxxxxxxxxxx>" out
'
Cheers,
-- Rafael
