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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Drew DeVault" <sir@xxxxxxxxx> writes:

> This would be better, yeah, but at that point it's pretty weird, like
> why are we prompting for this CLI flag and not any others? The answer is
> just for legacy reasons. There's no inherent justification for it.

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.

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.

The weighing done, perhaps in the original author's mind, back when
send-email was written would certainly not be based on any concrete
numbers, either.  But as one undisputable fact we know [*2*] is that
quite many people are already used to the behaviour we currently
have.  While some of them may welcome change, others will complain
if they are forced to relearn what they have committed to their
muscle memory.  

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



[Footnote]

*1* After all, these two affect where the readers find the message,
    i.e. in the archive or mailbox of which mailing list, and where
    in relation to other messages in the list.

*2* Purely based on how widely git is used.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux