Re: git send-email should not allow 'y' for in-reply-to
Jeff King p...@peff.net writes: On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote: ... More seriously, I agree that re-wording the question is a reasonable thing to do. I do not use send-email, either, so I don't have a strong opinion on it. The suggestions you made: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. Has anything come out of this discussion? Is the current phrasing fine as-is? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git send-email should not allow 'y' for in-reply-to
[raising this UI wart to the git list] On 01/11/2013 01:42 AM, Peter Krempa wrote: On 01/11/13 07:31, Chunyan Liu wrote: This patch series is to... [snip] Please don't answer y when git send email shows the following prompt: Message-ID to be used as In-Reply-To for the first email? you should respond with a message ID there. Unfortunately we have a growing thread that contains submissions with this mistake. Anyone willing to patch upstream 'git send-email' to reject a simple 'y' rather than blindly sending a bad messageID for the in-reply-to field, to help future users avoid this mistake? Obviously, it won't help until the patch eventually percolates into distros, so it would be a few more months before we see the benefits, but down the road it will prevent confusing threads. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: git send-email should not allow 'y' for in-reply-to
On Fri, Jan 11, 2013 at 09:39:06AM -0700, Eric Blake wrote: Please don't answer y when git send email shows the following prompt: Message-ID to be used as In-Reply-To for the first email? you should respond with a message ID there. Unfortunately we have a growing thread that contains submissions with this mistake. Anyone willing to patch upstream 'git send-email' to reject a simple 'y' rather than blindly sending a bad messageID for the in-reply-to field, to help future users avoid this mistake? Obviously, it won't help until the patch eventually percolates into distros, so it would be a few more months before we see the benefits, but down the road it will prevent confusing threads. What version of git? Commit 51bbccf is in v1.7.12.1 and higher, and says: $ git show 51bbccf commit 51bbccfd1b4a9e2807413022c56ab05c835164fb Author: Junio C Hamano gits...@pobox.com Date: Tue Aug 14 15:15:53 2012 -0700 send-email: validate reconfirm interactive responses People answer 'y' to Who should the emails appear to be from? and 'n' to Message-ID to be used as In-Reply-To for the first email? for some unknown reason. While it is possible that your local username really is y and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. Fortunately, our interactive prompter already has input validation mechanism built-in. Enhance it so that we can optionally reconfirm and allow the user to pass an input that does not validate, and softly require input to the sender, in-reply-to, and recipient to contain @ and . in this order, which would catch most cases of mistakes. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
On 01/11/2013 09:47 AM, Jeff King wrote: On Fri, Jan 11, 2013 at 09:39:06AM -0700, Eric Blake wrote: Please don't answer y when git send email shows the following prompt: Anyone willing to patch upstream 'git send-email' to reject a simple 'y' What version of git? Commit 51bbccf is in v1.7.12.1 and higher, and says: $ git show 51bbccf commit 51bbccfd1b4a9e2807413022c56ab05c835164fb Author: Junio C Hamano gits...@pobox.com Date: Tue Aug 14 15:15:53 2012 -0700 send-email: validate reconfirm interactive responses People answer 'y' to Who should the emails appear to be from? and 'n' to Message-ID to be used as In-Reply-To for the first email? for some unknown reason. While it is possible that your local username really is y and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. Awesome! Already implemented! In the case that sparked this particular email, the culprit was using 1.7.3.4; earlier this month, a separate culprit to the same libvirt mailing list was using 1.7.11.7. I was right about it needing to take a few months to percolate to the actual users. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: git send-email should not allow 'y' for in-reply-to
On 11 January 2013 08:47, Jeff King p...@peff.net wrote: On Fri, Jan 11, 2013 at 09:39:06AM -0700, Eric Blake wrote: Please don't answer y when git send email shows the following prompt: Message-ID to be used as In-Reply-To for the first email? you should respond with a message ID there. Unfortunately we have a growing thread that contains submissions with this mistake. snip/ People answer 'y' to Who should the emails appear to be from? and 'n' to Message-ID to be used as In-Reply-To for the first email? for some unknown reason. While it is possible that your local username really is y and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. I have never used Git's email support so this doesn't affect me one way or another but it seems that checking the results is fixing the symptoms, not the problem? I apologize if this was already discussed but I couldn't find such a discussion. I was wondering if it might be a better idea to change the wording of the questions if they have proven so confusing? The first time (just now) that I read Message-ID to be used as In-Reply-To for the first email?, it clearly seemed like a yes/no question to me. :-) How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. I'm a little surprised that Who should the emails appear to be from? would be interpreted as a yes/no question but we could rephrase that similarly as Provide the name of the email sender: (I don't really like this particular version but you get the idea). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote: People answer 'y' to Who should the emails appear to be from? and 'n' to Message-ID to be used as In-Reply-To for the first email? for some unknown reason. While it is possible that your local username really is y and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. I have never used Git's email support so this doesn't affect me one way or another but it seems that checking the results is fixing the symptoms, not the problem? I apologize if this was already discussed but I couldn't find such a discussion. It depends on who you are. If you are the person running send-email, then the symptom is your confusion. If you are somebody else, the symptom is somebody else sending out a bogus email. That patch fixes only the latter. :) More seriously, I agree that re-wording the question is a reasonable thing to do. I do not use send-email, either, so I don't have a strong opinion on it. The suggestions you made: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
Jeff King p...@peff.net wrote in message news:2013085417.ga12...@sigill.intra.peff.net... On Fri, Jan 11, 2013 at 10:43:39AM -0800, Hilco Wijbenga wrote: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. Suggestion: Message-ID to use as In-Reply-To for the first email:. Simple and unlikely to generate a y or n response. Putting Message-ID first makes it more obvious what data is being asked for by this prompt. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
On Fri, Jan 11, 2013 at 08:13:57PM +, Matt Seitz (matseitz) wrote: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. Suggestion: Message-ID to use as In-Reply-To for the first email:. Simple and unlikely to generate a y or n response. Putting Message-ID first makes it more obvious what data is being asked for by this prompt. You'd think. But the existing message that has been causing problems is: Message-ID to be used as In-Reply-To for the first email? which is more or less what you are proposing. I do think a colon rather than a question mark helps indicate that the response is not yes/no. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
On Fri, Jan 11, 2013 at 10:23 PM, Jeff King p...@peff.net wrote: On Fri, Jan 11, 2013 at 08:13:57PM +, Matt Seitz (matseitz) wrote: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. Suggestion: Message-ID to use as In-Reply-To for the first email:. Simple and unlikely to generate a y or n response. Putting Message-ID first makes it more obvious what data is being asked for by this prompt. You'd think. But the existing message that has been causing problems is: Message-ID to be used as In-Reply-To for the first email? which is more or less what you are proposing. I do think a colon rather than a question mark helps indicate that the response is not yes/no. That is true. I'm definitely not a wording person, but assuming people who make the mistake probably don't read the whole sentence out of laziness (that might be somehow extreme though ;), starting it with what makes it obvious at first sight that you can't answer yes/no. That is not true if the message starts with Message-ID .. which doesn't look like a question. Now it feels like you have agree or not. Antoine, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
Antoine Pelisse apeli...@gmail.com writes: On Fri, Jan 11, 2013 at 10:23 PM, Jeff King p...@peff.net wrote: On Fri, Jan 11, 2013 at 08:13:57PM +, Matt Seitz (matseitz) wrote: How about What Message-ID to use as In-Reply-To for the first email? or Provide the Message-ID to use as In-Reply-To for the first email:. seem fine to me. Maybe somebody who has been confused by it can offer more. At any rate, patches welcome. Suggestion: Message-ID to use as In-Reply-To for the first email:. Simple and unlikely to generate a y or n response. Putting Message-ID first makes it more obvious what data is being asked for by this prompt. You'd think. But the existing message that has been causing problems is: Message-ID to be used as In-Reply-To for the first email? which is more or less what you are proposing. I do think a colon rather than a question mark helps indicate that the response is not yes/no. That is true. I'm definitely not a wording person, but assuming people who make the mistake probably don't read the whole sentence out of laziness (that might be somehow extreme though ;), starting it with what makes it obvious at first sight that you can't answer yes/no. That is not true if the message starts with Message-ID .. which doesn't look like a question. Now it feels like you have agree or not. The exchange, when you do not have a configuration, goes like this: $ git send-email 0001-filename-of-the-patch.patch 0001-filename-of-the-patch.patch Who should the emails be sent to (if any)? junio Are you sure you want to use junio [y/N]? y Message-ID to be used as In-Reply-To for the first email (if any)? Why not do this instead? $ git send-email 0001-filename-of-the-patch.patch 0001-filename-of-the-patch.patch Who should the emails be sent to (if any)? junio Are you sure you want to use junio [y/N]? y Is this a response to an existing message [y/N]? y What is the Message-ID of the message you are replying to? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
On Fri, Jan 11, 2013 at 11:18 PM, Junio C Hamano gits...@pobox.com wrote: The exchange, when you do not have a configuration, goes like this: $ git send-email 0001-filename-of-the-patch.patch 0001-filename-of-the-patch.patch Who should the emails be sent to (if any)? junio Are you sure you want to use junio [y/N]? y Message-ID to be used as In-Reply-To for the first email (if any)? Why not do this instead? $ git send-email 0001-filename-of-the-patch.patch 0001-filename-of-the-patch.patch Who should the emails be sent to (if any)? junio Are you sure you want to use junio [y/N]? y Is this a response to an existing message [y/N]? y I'm not sure about the extra question. If the user doesn't care, he will probably use the empty default, which will result in the same number of steps. If the user cares, he probably knows what he's doing and will give a sensible value. What is the Message-ID of the message you are replying to? I would simply go for: What Message-ID are you replying to (if any)? If I don't know what to answer, I would definitely not say y/yes/n/no, but press enter directly. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
Antoine Pelisse apeli...@gmail.com writes: I would simply go for: What Message-ID are you replying to (if any)? If I don't know what to answer, I would definitely not say y/yes/n/no, but press enter directly. Sounds sensible (even though technically you reply to a message that has that message ID, and not to a message ID ;-)). Any better phrasing from others? If not, I'd say we adopt this text. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
On 12/01/2013 10:54 AM, Junio C Hamano wrote: Antoine Pelisse apeli...@gmail.com writes: I would simply go for: What Message-ID are you replying to (if any)? If I don't know what to answer, I would definitely not say y/yes/n/no, but press enter directly. Sounds sensible (even though technically you reply to a message that has that message ID, and not to a message ID ;-)). Any better phrasing from others? If not, I'd say we adopt this text. I guess it depends on how much we mind if people accidentally miss the message ID. If we don't mind much, we could say something like: What Message-ID are you replying to [Default=None]? If we are concerned that when a Message-ID exists, it should be provided, we could split to 2 questions: Are you replying to an existing Message [Y/n]? And then, if the answer is Y, What Message-ID are you replying to? Regards, Ben -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git send-email should not allow 'y' for in-reply-to
Ben Aveling bena@optusnet.com.au writes: On 12/01/2013 10:54 AM, Junio C Hamano wrote: Antoine Pelisse apeli...@gmail.com writes: I would simply go for: What Message-ID are you replying to (if any)? If I don't know what to answer, I would definitely not say y/yes/n/no, but press enter directly. Sounds sensible (even though technically you reply to a message that has that message ID, and not to a message ID ;-)). Any better phrasing from others? If not, I'd say we adopt this text. I guess it depends on how much we mind if people accidentally miss the message ID. If we don't mind much, we could say something like: What Message-ID are you replying to [Default=None]? If we are concerned that when a Message-ID exists, it should be provided, we could split to 2 questions: Are you replying to an existing Message [Y/n]? And then, if the answer is Y, What Message-ID are you replying to? Eewww. Now we come back to full circles. It sometimes helps to follow the in-reply-to chain to see what has already been said in the thread, I guess ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
