| Message ID | 20200827175552.132193-1-sir@cmpwn.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | send-email: do not prompt for In-Reply-To | expand |
Drew DeVault <sir@cmpwn.com> writes: > Most mailing lists prefer that new patchsets and their revisions are > placed into a new thread. Additionally, knowledge of what In-Reply-To > means and where to find the Message-Id to fill in are domain-specific > and confusing to new users. In the niche situations where this is called > for, the --in-reply-to flag is sufficient. > > A config option, sendemail.promptInReplyTo, has been added to re-enable > the old behavior. We do not break existing users' habits without a good reason, and a subjective "this is the way I prefer" is *not* a good reason. If/when the claim "most mailing lists prefer" can be substantiated, we'd need to devise a transition plan to flip the default over several releases. Here is how I would envision the plan should go. (0) Introduce sendemail.promptInReplyTo that defaults to true; this can be done today and it would be a genuine improvement for those who want the new behaviour, without hurting any existing users. (1) Substantiate the "most mailing list prefer" claim. If we cannot, we stop here. Otherwise we would move to the next step. (2) Teach "git send-email" to issue a warning message when the telling the user that the default will be flipped in some future version of Git and optionally ask them to tell us to stop on the mailing list, when sendemail.promptInReplyTo configuration variable is not set. Advertise the future flip of the default in other channels, too. (3) Wait for at least a few releases. Monitor the mailing list and other channels for objections, and if it becomes clear that we misjudged in step (1), stop the transition plan by reverting to the state before step (2) (i.e. not to before step (0)). (4) Flip the default and tweak the message to tell those users who still do not have sendemail.promptInReplyTo variable set that the default have changed, and if they want to get prompted, they must set the variable to true. Also stop asking them to tell us to stop---at this point we are committed and will not go back. (5) Waiting for several releases (6) Remove the code to give messages for users who do not have the configuration variable.
Junio C Hamano <gitster@pobox.com> writes: > Drew DeVault <sir@cmpwn.com> writes: > >> Most mailing lists prefer that new patchsets and their revisions are >> placed into a new thread. Additionally, knowledge of what In-Reply-To >> means and where to find the Message-Id to fill in are domain-specific >> and confusing to new users. In the niche situations where this is called >> for, the --in-reply-to flag is sufficient. >> >> A config option, sendemail.promptInReplyTo, has been added to re-enable >> the old behavior. > > We do not break existing users' habits without a good reason, and a > subjective "this is the way I prefer" is *not* a good reason. Having said that (and I am not retracting anything I said in the message I am responding to), I haven't seen this prompt triggering for me when I use send-email, with or without --in-reply-to option on the command line. Admittedly I use a wrapper around "git send-email" to add minimum set of command line options that are always used (they are --from, --envelope-sender, and --smtp-server) but I do not think they have effect on the use of in-reply-to prompt. What are we doing differently, I wonder?
Do you have sendemail.to set in your local git config?
Okay, thanks for the info! I'll take this back to the drawing board and come up with a plan which follows more closely to that.
On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote:
> Do you have sendemail.to set in your local git config?
I do and can't reproduce either; which version of git do you have this
problem with?
Carlo
"Drew DeVault" <sir@cmpwn.com> writes:
> Do you have sendemail.to set in your local git config?
Yes, and I'd assume most mailing list have a single to: address, and
people use a repository to interact with just a single project, so I
think it would be natural to have it in the per-repository
configuration file. Is it true that you do not set it and that the
lack of the configuration is why you are getting prompted?
I suspect that it may not make much sense for the presense of
sendemail.to to affect prompting for other header fields (iow, my
not getting prompted might be a bug).
Thanks.
On Thu Aug 27, 2020 at 3:21 PM EDT, Junio C Hamano wrote: > Yes, and I'd assume most mailing list have a single to: address, and > people use a repository to interact with just a single project, so I > think it would be natural to have it in the per-repository > configuration file. Is it true that you do not set it and that the > lack of the configuration is why you are getting prompted? No, this didn't make sense, I was mistaken. This shouldn't be the cause.
I can reproduce both on git 2.28.0 and on github.com/git/git master.
On Thu, Aug 27, 2020 at 03:23:00PM -0400, Drew DeVault wrote:
> I can reproduce both on git 2.28.0 and on github.com/git/git master.
and you use --compose to send an email thread directly instead of
doing first `git-format-patch -o`?
Carlo
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > On Thu, Aug 27, 2020 at 03:14:57PM -0400, Drew DeVault wrote: >> Do you have sendemail.to set in your local git config? > > I do and can't reproduce either; which version of git do you have this > problem with? Any recent version of git-send-email, I would say. The relevant code snippets are: my $prompting = 0; if (!@initial_to && !defined $to_cmd) { my $to = ask("$to_whom ", default => "", valid_re => qr/\@.*\./, confirm_only => 1); push @initial_to, parse_address_line($to) if defined $to; # $prompting++; } ... @initial_to = process_address_list(@initial_to); @initial_cc = process_address_list(@initial_cc); @initial_bcc = process_address_list(@initial_bcc); if ($thread && !defined $initial_in_reply_to && $prompting) { $initial_in_reply_to = ask( __("Message-ID to be used as In-Reply-To for the first email (if any)? "), default => "", valid_re => qr/\@.*\./, confirm_only => 1); } where initial_to is set either from the command line or sendemail.to configuration variable and before the control reaches this section of the code. In addition to realizing "ah, To: address is not given so we need to ask" and ask the to address, it says "since we have already interatively asked the end-user anyway, we can and should ask other things as well" by incrementing $prompting. That feels both understandable and bogus at the same time. To: is pretty much required (yes, you can use cc: and bcc: without any address on To:, but that is not something you'd usually do to send patches to mailing lists), so lack of it means either asking interactively or aborting. But other things like in-reply-to are optional, and tying the decision to prompt for them or not does not feel OK.
Do you think this whole workstream could be averted by dropping the $prompting check in the in-reply-to branch? Or would that still constitute a breaking change to user workflows?
On Thu, Aug 27, 2020 at 12:35 PM Drew DeVault <sir@cmpwn.com> wrote: > Do you think this whole workstream could be averted by dropping the > $prompting check in the in-reply-to branch? > > Or would that still constitute a breaking change to user workflows? I think the "breaking change" is changing the default (which needs fixing as well). but an interesting idea would be to add a config so the prompting could be skipped which would be something that people could add to their per repository config (as needed). Carlo
On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote: > > That feels both understandable and bogus at the same time. To: > is pretty much required (yes, you can use cc: and bcc: without any > address on To:, but that is not something you'd usually do to send > patches to mailing lists), so lack of it means either asking > interactively or aborting. But other things like in-reply-to are > optional, and tying the decision to prompt for them or not does not > feel OK. but trying to "fix" this breaks 10 year old tests, so it is obvious that everyone already expects it to work this way (probably hidden by the fact most people don't let git-send-email prompt for "To:") the patch after the scissors attempts to document the current "Legacy" behaviour which should be worth doing regardless of what is done with this patch. but I suspect it might be worth adding a new configuration flag like the one that was propossed so that the prompting could be set per repository to either "Always" (for when forgetting it will break the threads in lists that care, like this one) and "Never" (for when the lists explicitally ask mails to be send without one, because they use patchew or equivalent (ex: qemu-devel[1])). Carlo [1] https://wiki.qemu.org/Contribute/SubmitAPatch --- >8 --- Subject: [PATCH] send-email: document logic for In-Reply-To prompting Eventhough there doesn't seem to be a good reason for it, it is the way it has been implemented for the last 10 years. Document the current behaviour (which the tests also depend on) before it can be tweaked by a future per repository setting. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> --- Documentation/git-send-email.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 0a69810147..8e9ebb3fac 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -108,8 +108,7 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`: [PATCH v2 2/3] New tests [PATCH v2 3/3] Implementation + -Only necessary if --compose is also set. If --compose -is not set, this will be prompted for. +If --compose is not set, and there is no known "To:" this will be prompted for. --subject=<string>:: Specify the initial subject of the email thread.
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > On Thu, Aug 27, 2020 at 12:34:02PM -0700, Junio C Hamano wrote: >> >> That feels both understandable and bogus at the same time. To: >> is pretty much required (yes, you can use cc: and bcc: without any >> address on To:, but that is not something you'd usually do to send >> patches to mailing lists), so lack of it means either asking >> interactively or aborting. But other things like in-reply-to are >> optional, and tying the decision to prompt for them or not does not >> feel OK. > > but trying to "fix" this breaks 10 year old tests, so it is obvious > that everyone already expects it to work this way (probably hidden > by the fact most people don't let git-send-email prompt for "To:") Oh, I agree with that 100%. > -Only necessary if --compose is also set. If --compose > -is not set, this will be prompted for. > +If --compose is not set, and there is no known "To:" this will be prompted for. The updated sentence structure, with or without the mention of "to:", reads much better than the original. The original told them that they must give it from the command line in "--compose" mode, because they will not be given the chance to give it interactively, and the intended target audience was those who want to send a message with in-reply-to (which is natural, as this is a description for that option). The updated message says the same thing, but is audience-neutral and tries to be more useful to folks who are not responding to any message. I.e. outside "--compose" mode, you'll be asked if you want to make it a response, unless you gave "to:". By losing the "we won't ask so you must give it from the command line" message in the original, the resulting description has become easier to follow, I think. Those who do want to add the header, when they reach this description in the manual, already knows that there is a command line option. To help those who do not want to add this header, it would probably be more helpful to tell what to do when prompted (like "you can give an empty answer to tell the command that you are not responding to any message"). Thanks.
On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote: > To help those who do not want to add this header, it would probably > be more helpful to tell what to do when prompted (like "you can give > an empty answer to tell the command that you are not responding to > any message"). I don't like this solution. We should make it harder to do the wrong thing, and easier to do the right thing. It would be helpful for git to take an opinionated stance on the right way to send emails with it, since no one else is really in the position to. This behavior has confused many people that I've spoken with and makes for a rough introduction to a tool which people are already loathe to learn. git send-email is really the best way to send emails with git, and will save the user a lot of trouble in the future if they figure it out, so I want it to be as easy to figure out as possible. Even so, I understand the concerns raised so far. I haven't started on v2 yet, but my rough plan is to add a config option along the lines of sendemail.verbosePrompts, defaulted to on for now, which enables the present-day behavior, along with a message stating the intention to change the behavior in a future release, and an invitation to comment on the mailing list. The behavior of this flag if set to false would be equivalent to removing the $prompting condition in the if statement which controls whether or not this prompt is shown.
Oh, and I should mention the fact that this breaking change is less severe than we initially thought, only breaking an edge case - when --to is not specified - so it's likely to have a pretty small impact. We'll find out when someone emails us to complain, I suppose.
"Drew DeVault" <sir@cmpwn.com> writes: > On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote: >> To help those who do not want to add this header, it would probably >> be more helpful to tell what to do when prompted (like "you can give >> an empty answer to tell the command that you are not responding to >> any message"). > > I don't like this solution. We should make it harder to do the wrong > thing, and easier to do the right thing. Carlo and I were discussing how best to describe the behaviour we have better to the users, which is unrelated to any code change that would be required to "make it harder make it easier." We need to do so to help users in the meantime, before any behaviour change (which need to happen over several releases, as outlined earlier) happens.
On Thu Aug 27, 2020 at 7:23 PM EDT, Junio C Hamano wrote: > Carlo and I were discussing how best to describe the behaviour we > have better to the users, which is unrelated to any code change that > would be required to "make it harder make it easier." > > We need to do so to help users in the meantime, before any behaviour > change (which need to happen over several releases, as outlined > earlier) happens. Ah, I see what you mean. I'll add some messaging like that in my v2, but the point's likely moot anyway since I expect to have the patch ready for the next release.
"Drew DeVault" <sir@cmpwn.com> writes: > Oh, and I should mention the fact that this breaking change is less > severe than we initially thought, only breaking an edge case - when --to > is not specified - so it's likely to have a pretty small impact. We'll > find out when someone emails us to complain, I suppose. I agree that it is likely that only very small population even gets bittn by this "in-reply-to gets prompted" issue, because it is unlikely for users not to give "to:" address in one way or another and let the prompt logic to ask them. Which means that it is OK to stop at step (0) in the long transition sequence I outlined in a previous message from me. That is, introduce a configuration variable that can be set to 'no' by those who do not want to be prompted for "in-reply-to:" when they did not give "to:" and let the prompt logic to ask "to:", document the variable well [*1*], and make sure the default behaviour when the variable is not set is the same as now. That way, we do not even need to debate if it is true that most users do not want in-reply-to (i.e. step (1)). That's the kind of thing that is very hard to establish. The minority who wants to use an updated behaviour can just set the configuration once and the problem is behind them. The minority who wants to keep the current behaviour do not have to do anything. And there is no impact to the majority of people either way. I hate having to go through a multi cycle compatibility-breaking transition, because it would consume unnecessary resources from this list (i.e. developer attention is the most scarce common resource that must be shared across topics here), and we would avoid that cost altogether because the affected population seems to be small enough that it is not worth going through the rigmarole of flipping the default. That alone is a big plus. It seems like we managed to cut down the scope quite a bit. Thanks. [Footnote] *1* As a part of "document the variable well", we can include a message tweak for the prompt that asks for "in-reply-to:" to say something like "if you never want to be prompted for in-reply-to:, you can set this variable" when the variable is not set at all. Those who did set the variable but still are getting the prompt are explicitly opting into keeping the current behaviour by setting it to 'yes', so they do not have to see that extra part of the message.
On Thu Aug 27, 2020 at 9:02 PM EDT, Junio C Hamano wrote: > The minority who wants to use an updated behaviour can just set the > configuration once and the problem is behind them. The minority who > wants to keep the current behaviour do not have to do anything. And > there is no impact to the majority of people either way. Eh, this would defeat the purpose. I hate the multi-cycle compatibility-breaking dance as much as the next guy, but the whole reason I'm here is to solve a real problem which noobs are encountering. I on-board a lot of people with git-send-email and I've heard questions and confusions over this prompt at least 10 times in the past few years. Compatibility breakage is annoying but this is a real problem which real users are having real difficulty with, and the demographic of affected user may be particularly ill-equipped to deal with it on their own.
On Thu Aug 27, 2020 at 9:02 PM EDT, Junio C Hamano wrote: > I agree that it is likely that only very small population even gets > bittn by this "in-reply-to gets prompted" issue, because it is > unlikely for users not to give "to:" address in one way or another > and let the prompt logic to ask them. The merits of this thread's proposal aside, send-email's prompting has always seemed half-baked to me - it often doesn't even show up, and doesn't prompt for some things that would be useful like additional CCs (and if you're setting In-Reply-To, there are probably additional CCs). The prompts have helped me not flub emails before, but arguably that's not good since they're often not even shown and someone may come to rely on their presence only to later accidentally turn them off. Anyway, it's worth noting that, because the prompts *do* exist, half-baked as they are, it's not really safe to assume that nobody sees them. There might be a sizable population out there never specifying "--to" because they know they'll be prompted for it.
On Thu Aug 27, 2020 at 9:44 PM EDT, Raymond E. Pasco wrote: > Anyway, it's worth noting that, because the prompts *do* exist, > half-baked as they are, it's not really safe to assume that nobody sees > them. There might be a sizable population out there never specifying > "--to" because they know they'll be prompted for it. I hardly ever use --to for one-off patches or repositories which I'm not regularly contributing to, and I expect that prompt. In-Reply-To has a much less compelling argument, though, as Junio pointed out, given that it's often not necessary or desirable, whereas for "to", every email has to have at least one recipient to make sense.
On Thu Aug 27, 2020 at 6:57 PM EDT, Junio C Hamano wrote: > To help those who do not want to add this header, it would probably > be more helpful to tell what to do when prompted (like "you can give > an empty answer to tell the command that you are not responding to > any message"). I'm trying to come up with a message like this for a reduced-scope initial patch, but I'm drawing up a blank when the goal is to avoid confusing users who don't understand this. The goal is to remove domain-specific knowledge about email, namely how the In-Reply-To and Message-Id headers work, which is uncommon knowledge among new users. "You can give an empty answer if you are not responding to any message" could confuse users, because they might think -v2 is a "response", or maybe they've written the patch in response to a discussion on the -users mailing list, or any other number of reasons. Now they have to figure out how to answer this prompt, even if the mailing list they're sending it to isn't expecting it to be a reply. I came up with a number of alternative wordings but they all ultimately failed to this same problem. In-Reply-To is such an arcane and tangental piece of knowledge so far removed from git, and so little information is given to the user to help them understand (1) what it is, and (2) whether they need it or not, and (3) where to find it, that this prompt just seems totally awful to me. It'd be like if we prompted someone to enter their display EDID when filing a bug for a video game. Could it be useful? It's unlikely. Is the user likely to know what the hell an EDID is? Almost certainly not! "Legitimate" use-cases like qemu-devel or not, this is only ever going to confuse new users, and I think that qemu is wrong for encouraging users to deal with it. Or they would be wrong, but I looked into it and, the qemu wiki advises that the user does *not* use in-reply-to: https://wiki.qemu.org/Contribute/SubmitAPatch Nor does patchew make it easy to extract the message ID from their interface for this use-case. I'm not sure where this qemu idea is coming from. Is compatibility-breaking migrations a nightmare? Well, maybe. Is that nightmare worth such a trivial problem? Well, it seems trivial to those of us who have been using it for years, but I can assure you there are plenty of new users who shut down at this step. I hate to be a nuisance over such a seemingly simple problem, but there are a lot of new users who are struggling here and I care about their struggle. What path should we take to fixing this issue for them?
On Fri Aug 28, 2020 at 2:39 PM EDT, Drew DeVault wrote: > "You can give an empty answer if you are not responding to any message" > could confuse users, because they might think -v2 is a "response", or > maybe they've written the patch in response to a discussion on the > -users mailing list, or any other number of reasons. Now they have to > figure out how to answer this prompt, even if the mailing list they're > sending it to isn't expecting it to be a reply. I came up with a number > of alternative wordings but they all ultimately failed to this same > problem. These *are* all reasons why a patch would be sent as a reply. You can moderate your own lists however you like, but that does not mean that patches being replies to other mails is 1) wrong or useless, or 2) not in wide use. I wish the user experience were a bit smoother for those of us who aren't dedicated Emacs manglers, but things like scissors lines help a bit. > "Legitimate" use-cases like qemu-devel or not, this is only ever going > to confuse new users, and I think that qemu is wrong for encouraging > users to deal with it. qemu-devel was given by Carlo as an example of a list which does *not* keep discussion together in threads; the example give of a list which *does* keep things together in threads was the Git list itself (surely the normative list for Git, if there is such a thing). It's too useful to hackers (and presumably maintainers), I don't think anyone is going to stop. Looking at this in isolation from the polemics about list practices, it's pretty clear that the way send-email prompts for things is not logical. Axing the In-Reply-To prompt would be one way to make it logical, because the only other prompt is the To prompt; this is removal of a prompt users may expect, but by being so inconsistent, the software itself already removes the prompt when I'm expecting it! There may be other ways to make it logical, like having the appearance of the In-Reply-To prompt depend solely on whether a message ID was already provided or not (but since a message ID is not mandatory, it's weird to prompt for it and not for, say, additional CCs). Since every mail client I've ever seen has a "reply" button, I don't think the concept of a reply is eldritch arcana that users must be protected from. It's annoying to have to get a Message-ID and paste it, sure. It would be nice if a mail client could do that for me (I think dedicated Emacs manglers are insulated from this problem for that reason). Probably whoever prompted for it in the first place just didn't want to flub a message by leaving it out, which wouldn't be an issue for a client command invoked as some variation on "reply all".
"Drew DeVault" <sir@cmpwn.com> writes: > "You can give an empty answer if you are not responding to any message" > could confuse users, because they might think -v2 is a "response", or > maybe they've written the patch in response to a discussion on the > -users mailing list, or any other number of reasons. "Type the value you would have given to --in-reply-to command line option (if you forgot to use it), or leave this field empty" perhaps? Those who do not know should be able to learn what "--in-reply-to" is. A prompt help is not the place to do a documentation. > I hate to be a nuisance over such a seemingly simple problem, but there > are a lot of new users who are struggling here and I care about their > struggle. What path should we take to fixing this issue for them? The ideal way would be to craft step (0) well enough so that new users trigger the To: prompt in the first place, which would automatically make the problem disappear ;-)
On Fri Aug 28, 2020 at 5:00 PM EDT, Junio C Hamano wrote: > "Drew DeVault" <sir@cmpwn.com> writes: > > > "You can give an empty answer if you are not responding to any message" > > could confuse users, because they might think -v2 is a "response", or > > maybe they've written the patch in response to a discussion on the > > -users mailing list, or any other number of reasons. > > "Type the value you would have given to --in-reply-to command line > option (if you forgot to use it), or leave this field empty" > perhaps? Those who do not know should be able to learn what > "--in-reply-to" is. A prompt help is not the place to do a > documentation. 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 hate to be a nuisance over such a seemingly simple problem, but there > > are a lot of new users who are struggling here and I care about their > > struggle. What path should we take to fixing this issue for them? > > The ideal way would be to craft step (0) well enough so that new > users trigger the To: prompt in the first place, which would > automatically make the problem disappear ;-) Do you mean teaching users how to use --to upfront? Honestly the prompt seems totally fine to me, there's nothing wrong with a use-case which calls for typing your To address into the prompt. Hell, often I'll use it, or I'll use --annotate and write my To addresses in vim.
"Drew DeVault" <sir@cmpwn.com> 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.
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.
diff --git a/Documentation/config/sendemail.txt b/Documentation/config/sendemail.txt index cbc5af42fd..34ca8263d0 100644 --- a/Documentation/config/sendemail.txt +++ b/Documentation/config/sendemail.txt @@ -66,3 +66,10 @@ sendemail.forbidSendmailVariables:: To avoid common misconfiguration mistakes, linkgit:git-send-email[1] will abort with a warning if any configuration options for "sendmail" exist. Set this variable to bypass the check. + +sendemail.promptInReplyTo:: + Previous versions of linkgit:git-send-email[1] would prompt the user to + input an In-Reply-To header for every patchset sent. This was removed as + the default behavior, being generally undesirable on most mailing lists, + and confusing for new users. Set this variable to re-enable the old + behavior. diff --git a/git-send-email.perl b/git-send-email.perl index 1f425c0809..f3abccef6d 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -251,6 +251,7 @@ sub do_edit { my $validate = 1; my $target_xfer_encoding = 'auto'; my $forbid_sendmail_variables = 1; +my $prompt_in_reply_to = 0; my %config_bool_settings = ( "thread" => \$thread, @@ -265,6 +266,7 @@ sub do_edit { "annotate" => \$annotate, "xmailer" => \$use_xmailer, "forbidsendmailvariables" => \$forbid_sendmail_variables, + "promptinreplyto" => \$prompt_in_reply_to, ); my %config_settings = ( @@ -467,6 +469,7 @@ sub read_config { "batch-size=i" => \$batch_size, "relogin-delay=i" => \$relogin_delay, "git-completion-helper" => \$git_completion_helper, + "prompt-in-reply-to" => \$prompt_in_reply_to, ); # Munge any "either config or getopt, not both" variables @@ -978,7 +981,7 @@ sub expand_one_alias { @initial_cc = process_address_list(@initial_cc); @initial_bcc = process_address_list(@initial_bcc); -if ($thread && !defined $initial_in_reply_to && $prompting) { +if ($thread && !defined $initial_in_reply_to && $prompting && $prompt_in_reply_to) { $initial_in_reply_to = ask( __("Message-ID to be used as In-Reply-To for the first email (if any)? "), default => "",