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

From: Drew DeVault <sir@cmpwn.com>
Date: Aug 28, 2020, 21:35 UTC
Message-ID: <C58YB5DAHSZF.F67NZSQYAPF7@homura>
In-Reply-To: <xmqq7dtio3pa.fsf@gitster.c.googlers.com>

On Fri Aug 28, 2020 at 5:33 PM EDT, Junio C Hamano wrote:

Show 6 quoted lines

> 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?

Show 7 quoted lines

> 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.