Re: [PATCH] send-email: do not prompt for In-Reply-To

["Drew DeVault" <sir@cmpwn.com>]

On Fri Aug 28, 2020 at 5:33 PM EDT, Junio C Hamano wrote:
> I suspect that the legacy reason exists only because it was (thought
> to be) (a) common enough to make a series in response to an existing
> message than a thread starter and (b) "to:" and "in-reply-to:" are
> quite close to make sense to be asked together [*1*], back when the
> current behaviour was established, ? In other words, the "legacy
> reson" may have inherent justification for it.

I understand what you mean, but like you said, without a time machine to
peer into the mind of the original author, this is an assumption without
evidence. If we cannot come up with a renewed justification it... does
it really still hold on the basis that it may or may not have been
adequately justified at some point in the distant past?

> Your primary and only argument to flip the default not to ask about
> in-reply-to is, because, in your opinion, more users would want to
> send thread-starters than responses. I haven't seen the numbers,
> and more importantly I do not think anybody can expected to produce
> numbers that convince everybody (there are biases based on who's
> counting and what is counted), so I cannot buy such an argument
> blindly.

I would agree that this is part of my argument, but it's only a
supporting argument, not my primary argument. The primary argument is
that understanding and answering the prompt requires domain-specific
knowledge about email internals which are not normally presented to the
user. I am unaware of any mail client which makes the meaning or even
the existence of the Message-ID or In-Reply-To headers known to the user
without going out of their way to find it. Explaining the meaning of
these fields, how to find them for their mail client, and when to use
them, would be well outside the scope for the prompt itself.

No one has yet come forward to vouch for this branch as something they
actually depend on, by the way. It's just been people who are unaffected
making arguments that such a user may exist in theory. Maybe we could
figure it for sure out by putting a prompt in this branch, like you
initially suggested?

> That makes it the safest thing to give users a new choice without
> changing the default. That would allow us at least move forward.

Well, it'd be a start, and I may very well write that patch for the sake
of moving forward, as you say. But it doesn't solve the problem I came
here to solve, unless viewed as the first of several steps towards its
eventual removal.