REPLY
I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response. Faithfully, Ms.Ella Golan
REPLY
I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response. Faithfully, Ms.Ella Golan
REPLY
I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your response. Faithfully, Ms.Ella Golan
REPLY URGENT PLS.
Dear friend, Greetings to you, I got your contact through International business directory, my names are Hon.Dr. James Kabore from Burkina Faso, West Africa. I am a politician with government position. am pleased to contact you for your assistance to help me invest in real estate or any provitable sector in your country through you as my partner and as a citizen of your country. I am eager to visit in person with you and of course provide more details, once you reply and promise to assist. Because I am aware that most of well connected people very rarely use this means of approach via inter-net, for a huge business of this size due to scam syndicates out there. Waiting for your urgent respond. Best regards, Dr.James Kabore.
MASSAGE FROM Ms Safi>> Reply
Dear Friend, I am Ms Safi Kabore work with the department of Audit and accounting manager here in the Bank, There is this fund that was keep in my custody years ago,please i need your assistance for the transferring of thIs fund to your bank account for both of us benefit for life time investment and the amount is (US$4.5M DOLLARS). I have every inquiry details to make the bank believe you and release the fund in within 5 banking working days with your full co-operation with me after success. Note/ 50% for you why 50% for me after success of the transfer to your bank account. Below information is what i need from you so will can be reaching each other . 1)Private telephone number... 2)Age... 3)Nationality... 4)Occupation ... 5)Full name ... Thanks. Ms Safi Kabore
Re: Reply for Auto parts
Dear Good day. This is Kevin from Future Mould and Plastic Technology Co.,Ltd. We supply plastic products for SUZUKI with high quality and competitive price. For instance, Dashboard panel, Steering wheel cover, Control Panel, Air conditioner outlet, Seat fitting, Cup holder, Gloves box, Rear mirror cover, Door Handle, etc. We also have a professional design and production team, We're also satisfied with small batch of plastic parts customization and O.E.M services. Tks & br Kevin Trade Representative Shanghai Future Mould & Plastic Technology Co.,Ltd. Mb: +86 15801877587 (WhatsApp/WeChat)
I want you to Distribute my funds to less priviledge if interested reply now
I am still waiting for your reply to my letter to you, Get back to me so that I can give you more details.
I want you to Distribute my funds to less priviledge if interested reply now
Reply-to: hm-treasury_off...@my.com
You are lucky to have £1,800,000.00GBP as your compensation grant. JC
Reply
Greeting, I contacted you last two weeks and I got no response. I mentioned about my late client that has the same surname with you. He deposited the sum of US$10.5 million dollars in one of the bank here in our country and they have asked me to provide a next of kin.Kindly show your interest to work with me through my personal email addres(bukasarak...@gmail.com)to enable me forward the details of this project to you. Regards, Barrister Buka Saraki bukasarak...@gmail.com
URGENT REPLY NEEDED,REMINDER
Hello Dear, We are global financial provider, led by a dynamic Investment team. We are providing corporate and Personal Loan at 3% Interest Rate for a duration of 2 to 20 Years. We also pay 1% commission to brokers/person, who introduce project owners for finance or other opportunities. Contact us immediately for more information. Yours faithfully, Patrick Mulliun
How are you doing today? Please read my email and reply me!!
Dear Sir/Madam, How are you doing today? My name is Billy Wilfred. I am California, United States of America. I am a broker of Project Financing Firm who has cutting edge and group capital fund, they can finance any lucrative project and help you to enhance your business plan. Are you in need of a Loan to Finance and Fund your Project or Company? Are you an Investor, Real Estate developer, Construction Company, etc? or Do you need a loan to keep your investment or business going on in order to have a different look? Have you been trying to obtain a Loan from Banks or Loan Companies and got Ripped off and they have refused to grant you the Loan because of bad credit? do not close your company and stop your project because of bankruptcy, we are here for you for real, please be happy, rejoice and celebrate because your solution have come, we will end your financial worries now. Therefore come to us, we will grant you the loan you need without delay. We offer all types of non-recourse Loan and Funding at a low Interest Rate of The categories of Loan Financial Funding we offered include but not limited to: Business Loan, Personal Loan, Company Loan, Mortgage Loan, Debt Consolidation and Financial Funding for both Turnkey and mega projects etc from a minimum of Euro / US$1Million to Euro / US$5 Billion Max. Most importantly, Note that the loan company DO NOT charge any upfront fee or advance fee. This message is not scam for what so ever. This is 100% real, legal and legitimate loan company office in Turkey. Kindly get in touch for further details and procedures. Thanks for your cooperation with us. I will be waiting for your response. Further more details and directives contact me on my private email: bwilalessan...@gmail.com Thank you & best regards, Billy Wilfred. Contact me on my private email: bwilalessan...@gmail.com
Important Notice...Reply Now
My wife and I won the Euro Millions Lottery of £53 Million British Pounds and we have voluntarily decided to donate 1,000,000EUR(One Million Euros) to 5 individuals randomly as part of our own charity project. To verify our lottery winnings,please see our interview by visiting the web page below: telegraph.co.uk/news/newstopics/howaboutthat/11511467/Lincolnshire-couple-win-53m-on-EuroMillions.html Your email address was among the emails which were submitted to us by the Google Inc. as a web user; if you have received our email,kindly send us the below details so that we can transfer your 1,000,000.00 EUR(One Million Euros) to you in your own country. Full Names: Mobile No: Age: Occupation: Country: Send your response to: rmaxwel...@yahoo.com Best Regards, Richard & Angela Maxwell
Re: [PATCH] send-email: avoid duplicate In-Reply-To/References
On 18.04.2018 02:54, Eric Wong wrote: > Stefan Agner wrote: >> This addresses the issue reported here: >> https://public-inbox.org/git/997160314bbafb3088a401f1c09cc...@agner.ch/ > > Thanks for bringing this up. > >> --- a/git-send-email.perl >> +++ b/git-send-email.perl >> @@ -1642,10 +1642,15 @@ foreach my $t (@files) { >> elsif (/^Content-Transfer-Encoding: (.*)/i) { >> $xfer_encoding = $1 if not defined >> $xfer_encoding; >> } >> +elsif (/^In-Reply-To: (.*)/i) { >> +$in_reply_to = $1; >> +} >> +elsif (/^References: (.*)/i) { >> +$references = $1; >> +} > > References: can span multiple lines with --thread=deep in format-patch > (technically any header can be, but References: is common) I think that is ok because we do # First unfold multiline header fields ... A quick test with 3 patches in --thread=deep mode looks good: In-Reply-To: <87d48c04aae0594ebea7567827d08979ad346380.1524034203.git.ste...@agner.ch> References: <06ea66574abfb2dd66adee9996e5fb66903b95a3.1524034203.git.ste...@agner.ch> <87d48c04aae0594ebea7567827d08979ad346380.1524034203.git.ste...@agner.ch> -- Stefan
Re: [PATCH] send-email: avoid duplicate In-Reply-To/References
Stefan Agner wrote: > This addresses the issue reported here: > https://public-inbox.org/git/997160314bbafb3088a401f1c09cc...@agner.ch/ Thanks for bringing this up. > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -1642,10 +1642,15 @@ foreach my $t (@files) { > elsif (/^Content-Transfer-Encoding: (.*)/i) { > $xfer_encoding = $1 if not defined > $xfer_encoding; > } > + elsif (/^In-Reply-To: (.*)/i) { > + $in_reply_to = $1; > + } > + elsif (/^References: (.*)/i) { > + $references = $1; > + } References: can span multiple lines with --thread=deep in format-patch (technically any header can be, but References: is common)
[PATCH] send-email: avoid duplicate In-Reply-To/References
In case a patch already has In-Reply-To or References in the header (e.g. when the patch has been created with format-patch --thread) git-send-email should not add another pair of those headers. This is also not allowed according to RFC 5322 Section 3.6: https://tools.ietf.org/html/rfc5322#section-3.6 Avoid the second pair by reading the current headers into the appropriate variables. Signed-off-by: Stefan Agner --- This addresses the issue reported here: https://public-inbox.org/git/997160314bbafb3088a401f1c09cc...@agner.ch/ git-send-email.perl | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl index 2fa7818ca..7157397fd 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1642,10 +1642,15 @@ foreach my $t (@files) { elsif (/^Content-Transfer-Encoding: (.*)/i) { $xfer_encoding = $1 if not defined $xfer_encoding; } + elsif (/^In-Reply-To: (.*)/i) { + $in_reply_to = $1; + } + elsif (/^References: (.*)/i) { + $references = $1; + } elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) { push @xh, $_; } - } else { # In the traditional # "send lots of email" format, -- 2.17.0
git send-mail sends with duplicate In-Reply-To/References header fields
Hi, Using git format-patch --thread + send-mail leads to In-Reply-To/References headers added twice (with the very same value). This is not allowed according to RFC 5322 Section 3.6: https://tools.ietf.org/html/rfc5322#section-3.6 Ideally probably git-format-patch should be smart about whether In-Reply-To/References are already present... I noticed this after looking through emails catched by my spam filter more carefully. It seems that this particular violation is penalized quite harshly, leading to those emails landing in my spam folder. It seems that there are multiple kernel developers which use the above work flow and hence send emails not adhering to spec... -- Stefan
Reply Immediately
Good Day My name is Benjamin Joseph, an accountant with C&G Bank UK, there is an opportunity in our bank that I would like us to talk about so we can join hands together to achieve it for our benefit. please get back to me for details. Thanks you Benjamin Joseph.
REPLY BACK PLEASE
-- Hello dear, How are you doing today? I got your contact from a directory and picked interest to communicate you by faith, though we have not met before, I believe we can achieve something together. My husband died few years ago after battling with brain cancer, before his death, he deposited ($10.5 Million) in one of the financial institution. He wanted to establish coco processing factory and also real estate business. After the death of my husband, I have been receiving all manner of life threats from the family members, now the pressure is getting more severe I decided to leave this country. Please can you partner with me and receive the fund in your account while I come over there with my son for investment. If you agree, get back for more details and what will be your commission for the assistance. Call me please: +22967650091 I wait for your reply, Doris Markkoh
QUICK REPLY
Would you like to be part of our supply? Please respond back to my private email on: kuanwaich...@gmail.com
Reply
Dear Doron, I plead an indulgence if I have invaded your privacy by receiving this mail from me without prior permission. With due respect, I contact you purposely based on the similarities of names between you and my deceased client who was an oil servicing contractor with shell petroleum in West Africa. This is about Nine years I have been searching the contacts of the relatives to my late client in order that they may come forward for the repatriation of the estate of my late client Engineer Victor Doron valued $16.4 Million but unfortunately all my search proved abortive and the Togo bank holding these funds issued me a last notice to bring the supposed heir/relatives before end of this year or they will have the account declared un serviceable thereby confiscating the funds hence my contact to you so that you may stand as the heir and receive the funds into your bank account since you are bearing same surname with my deceased client. I have the death certificate to send to you as well as deposit document as proof. The sharing ratio of the funds after a successful transfer to your bank account shall be 40/60 of which I do have trust that the funds will be secured pending my arrival to meet you in your country. Waiting to hear from you. Sincerely yours, Barrister Tamale David
Re: git-send-email: Support for Reply-To
Christian Ludwig writes: > this is the third iteration of this series. There was a request to > rebase the changes on the refactoring patch b6049542 ("send-email: > extract email-parsing code into a subroutine", 2017-12-15). This is > the result. Thanks. Let me Cc the party who did the refactoring, as it was unclear how much value the change that did only refactoring without having an actual user of the end result---now we do have code that uses it. > The diffstat is the same compared to the last revision. It could be > made smaller by sacrificing readibility and breaking the scheme > introduced by the refactoring patch. But I do agree that send-email's > readability could benefit from slicing it into handy functions. And the > refactoring patch reduces the nesting of loops/conditionals. Thanks. I compared the result of applying these on top of the refactoring commit, and cherry-picking the previous round on top of the same refactoring commit, and found that they pretty much result in the same code (which was an exercise for me to gain confidence in this code).
[PATCH v3 2/2] send-email: Support separate Reply-To address
In some projects contributions from groups are only accepted from a common group email address. But every individual may want to receive replies to her own personal address. That's what we have 'Reply-To' headers for in SMTP. So introduce an optional '--reply-to' command line option. This patch re-uses the $reply_to variable. This could break out-of-tree patches! Signed-off-by: Christian Ludwig --- Documentation/git-send-email.txt | 5 + contrib/completion/git-completion.bash | 2 +- git-send-email.perl| 18 +- t/t9001-send-email.sh | 2 ++ 4 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 8060ea35c..71ef97ba9 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -84,6 +84,11 @@ See the CONFIGURATION section for `sendemail.multiEdit`. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". +--reply-to=:: + Specify the address where replies from recipients should go to. + Use this if replies to messages should go to another address than what + is specified with the --from parameter. + --in-reply-to=:: Make the first mail (or all the mails with `--no-thread`) appear as a reply to the given Message-Id, which avoids breaking threads to diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index c7d5c7af2..4805b92ba 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2081,7 +2081,7 @@ _git_send_email () --compose --confirm= --dry-run --envelope-sender --from --identity --in-reply-to --no-chain-reply-to --no-signed-off-by-cc - --no-suppress-from --no-thread --quiet + --no-suppress-from --no-thread --quiet --reply-to --signed-off-by-cc --smtp-pass --smtp-server --smtp-server-port --smtp-encryption= --smtp-user --subject --suppress-cc= --suppress-from --thread --to diff --git a/git-send-email.perl b/git-send-email.perl index 9eb12b5ba..707ec9eb7 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -57,6 +57,7 @@ git send-email --dump-aliases --[no-]cc * Email Cc: --[no-]bcc* Email Bcc: --subject * Email "Subject:" +--reply-to * Email "Reply-To:" --in-reply-to * Email "In-Reply-To:" --[no-]xmailer * Add "X-Mailer:" header (default). --[no-]annotate* Review each patch that will be sent in an editor. @@ -167,7 +168,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/; # Variables we fill in automatically, or via prompting: my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh, - $initial_in_reply_to,$initial_subject,@files, + $initial_in_reply_to,$reply_to,$initial_subject,@files, $author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time); my $envelope_sender; @@ -316,6 +317,7 @@ die __("--dump-aliases incompatible with other options\n") $rc = GetOptions( "sender|from=s" => \$sender, "in-reply-to=s" => \$initial_in_reply_to, + "reply-to=s" => \$reply_to, "subject=s" => \$initial_subject, "to=s" => \@initial_to, "to-cmd=s" => \$to_cmd, @@ -678,6 +680,7 @@ if ($compose) { my $tpl_sender = $sender || $repoauthor || $repocommitter || ''; my $tpl_subject = $initial_subject || ''; my $tpl_in_reply_to = $initial_in_reply_to || ''; + my $tpl_reply_to = $reply_to || ''; print $c < References: +Reply-To: Reply Result: OK EOF @@ -316,6 +317,7 @@ test_expect_success $PREREQ 'Show all headers' ' --dry-run \ --suppress-cc=sob \ --from="Example " \ + --reply-to="Reply " \ --to=t...@example.com \ --cc=c...@example.com \ --bcc=b...@example.com \ -- 2.16.2
git-send-email: Support for Reply-To
Hi, this is the third iteration of this series. There was a request to rebase the changes on the refactoring patch b6049542 ("send-email: extract email-parsing code into a subroutine", 2017-12-15). This is the result. The diffstat is the same compared to the last revision. It could be made smaller by sacrificing readibility and breaking the scheme introduced by the refactoring patch. But I do agree that send-email's readability could benefit from slicing it into handy functions. And the refactoring patch reduces the nesting of loops/conditionals. But it's your code, you decide. I can re-send a fixed-up v2 without the rebasing. So long, - Christian
Reply
-- I was wondering if you got my previous Email to you regarding my proposal? best regards Email:robertwort...@outlook.com
Re: [PATCH v2 2/2] send-email: Support separate Reply-To address
On 17 January 2018 at 19:08, Christian Ludwig wrote: > In some projects contributions from groups are only accepted from a > common group email address. But every individual may want to recieve > replies to her own personal address. That's what we have 'Reply-To' > headers for in SMTP. s/recieve/receive/ > Introduce an optional '--reply-to' command line option. Unfortunately > the $reply_to variable name was already taken for the 'In-Reply-To' > header field. To reduce code churn, use $reply_address as variable > name instead. "To reduce ..." no longer describes the patch, since v2 actually performs that refactoring in patch 1/2. "Unfortunately ..." is correct, but seems less relevant now. Except: I suppose that a non-git.git patch which uses $reply_to could start misbehaving now that this series changes the meaning of that variable. Just thinking out loud, it could make some sense to take patch 1/2 for sanity, but to then *not* re-use $reply_to for a new purpose, but to actually take your v1-patch as 2/2. Or, this potential problem can perhaps be ignored (except in the commit message?).. > Signed-off-by: Christian Ludwig "From:" and "Signed-off-by:" are different. Not sure if that's ok. Martin
Re: [PATCH v2 2/2] send-email: Support separate Reply-To address
On Wed, Jan 17 2018, Christian Ludwig jotted: > +if (defined $reply_to) { > + $reply_to =~ s/^\s+|\s+$//g; > + ($reply_to) = expand_aliases($reply_to); > + $reply_to = sanitize_address($reply_to); > +} Just a note to other reviewers: I found it odd to call a function with one argument and then enforce list context, but I see expand_aliases() expects to be called that way, and this is copied from a previous pattern earlier in the file. (As an aside, that code looks a bit odd, but then I see 302e04ea4d ("send-email: detect cycles in alias expansion", 2009-07-23) ) Looks good to me.
Re: [PATCH v2 2/2] send-email: Support separate Reply-To address
Christian Ludwig writes: > In some projects contributions from groups are only accepted from a > common group email address. But every individual may want to recieve > replies to her own personal address. That's what we have 'Reply-To' > headers for in SMTP. > > Introduce an optional '--reply-to' command line option. Unfortunately > the $reply_to variable name was already taken for the 'In-Reply-To' > header field. To reduce code churn, use $reply_address as variable > name instead. > > Signed-off-by: Christian Ludwig > --- > Documentation/git-send-email.txt | 5 + > contrib/completion/git-completion.bash | 2 +- > git-send-email.perl| 18 +- > t/t9001-send-email.sh | 2 ++ > 4 files changed, 25 insertions(+), 2 deletions(-) Thanks. While merging this with other topics in flight on 'pu', there were minor merge conflicts, especially with np/send-email-header-parsing that ends at b6049542 ("send-email: extract email-parsing code into a subroutine", 2017-12-15) that attempts to refactor the code that reads the header lines. As there is *no* real change that benefits by the refactoring accompanying the topic, it was a bit hard for me to say if it is needless code churn or if it is a good refactoring. I wonder if this change can be a good demonstration to measure the goodness of it. IOW, how would these two patches look if rebased on the result of merging b6049542 to today's 'master'? Would it make these two patches cleaner and easier to grok?
[PATCH v2 2/2] send-email: Support separate Reply-To address
In some projects contributions from groups are only accepted from a common group email address. But every individual may want to recieve replies to her own personal address. That's what we have 'Reply-To' headers for in SMTP. Introduce an optional '--reply-to' command line option. Unfortunately the $reply_to variable name was already taken for the 'In-Reply-To' header field. To reduce code churn, use $reply_address as variable name instead. Signed-off-by: Christian Ludwig --- Documentation/git-send-email.txt | 5 + contrib/completion/git-completion.bash | 2 +- git-send-email.perl| 18 +- t/t9001-send-email.sh | 2 ++ 4 files changed, 25 insertions(+), 2 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 8060ea35c..71ef97ba9 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -84,6 +84,11 @@ See the CONFIGURATION section for `sendemail.multiEdit`. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". +--reply-to=:: + Specify the address where replies from recipients should go to. + Use this if replies to messages should go to another address than what + is specified with the --from parameter. + --in-reply-to=:: Make the first mail (or all the mails with `--no-thread`) appear as a reply to the given Message-Id, which avoids breaking threads to diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 3683c772c..2a0dc4eef 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -2081,7 +2081,7 @@ _git_send_email () --compose --confirm= --dry-run --envelope-sender --from --identity --in-reply-to --no-chain-reply-to --no-signed-off-by-cc - --no-suppress-from --no-thread --quiet + --no-suppress-from --no-thread --quiet --reply-to --signed-off-by-cc --smtp-pass --smtp-server --smtp-server-port --smtp-encryption= --smtp-user --subject --suppress-cc= --suppress-from --thread --to diff --git a/git-send-email.perl b/git-send-email.perl index 0c07f48d5..9bf758307 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -56,6 +56,7 @@ git send-email --dump-aliases --[no-]cc * Email Cc: --[no-]bcc* Email Bcc: --subject * Email "Subject:" +--reply-to* Email "Reply-To:" --in-reply-to * Email "In-Reply-To:" --[no-]xmailer * Add "X-Mailer:" header (default). --[no-]annotate* Review each patch that will be sent in an editor. @@ -166,7 +167,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/; # Variables we fill in automatically, or via prompting: my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh, - $initial_in_reply_to,$initial_subject,@files, + $initial_in_reply_to,$reply_to,$initial_subject,@files, $author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time); my $envelope_sender; @@ -315,6 +316,7 @@ die __("--dump-aliases incompatible with other options\n") $rc = GetOptions( "sender|from=s" => \$sender, "in-reply-to=s" => \$initial_in_reply_to, + "reply-to=s" => \$reply_to, "subject=s" => \$initial_subject, "to=s" => \@initial_to, "to-cmd=s" => \$to_cmd, @@ -677,6 +679,7 @@ if ($compose) { my $tpl_sender = $sender || $repoauthor || $repocommitter || ''; my $tpl_subject = $initial_subject || ''; my $tpl_in_reply_to = $initial_in_reply_to || ''; + my $tpl_reply_to = $reply_to || ''; print $c < References: +Reply-To: Reply Result: OK EOF @@ -297,6 +298,7 @@ test_expect_success $PREREQ 'Show all headers' ' --dry-run \ --suppress-cc=sob \ --from="Example " \ + --reply-to="Reply " \ --to=t...@example.com \ --cc=c...@example.com \ --bcc=b...@example.com \ -- 2.15.1
Re: [PATCH] send-email: Support separate Reply-To address
> In some projects contributions from groups are only accepted from a > common group email address. But every individual may want to recieve > replies to her own personal address. That's what we have 'Reply-To' > headers for in SMTP. > > Introduce an optional '--reply-to' command line option. Unfortunately > the $reply_to variable name was already taken for the 'In-Reply-To' > header field. To reduce code churn, use $reply_address as variable > name instead. That $reply_to variable is only accessed in 6 lines. I wouldn't consider it that much of a code churn to rename it in a preparatory patch. > Signed-off-by: Christian Ludwig > --- > Documentation/git-send-email.txt | 5 + > git-send-email.perl | 18 +- > t/t9001-send-email.sh| 2 ++ > 3 files changed, 24 insertions(+), 1 deletion(-) Please add the new option to the completion script as well, to keep it up to date. > diff --git a/Documentation/git-send-email.txt > b/Documentation/git-send-email.txt > index 8060ea35c..c3bc622b1 100644 > --- a/Documentation/git-send-email.txt > +++ b/Documentation/git-send-email.txt > @@ -84,6 +84,11 @@ See the CONFIGURATION section for `sendemail.multiEdit`. > the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not > set, as returned by "git var -l". > > +--reply-to=:: > + Specify the address that replies from reciepients should s/reciepients/recipients/ And I don't like that "that" and would prefer e.g. "where" instead, but I'd rather leave this to the native English speakers. > + to go. Use this if replies to messages should go to another s/to go/go to/
[PATCH] send-email: Support separate Reply-To address
In some projects contributions from groups are only accepted from a common group email address. But every individual may want to recieve replies to her own personal address. That's what we have 'Reply-To' headers for in SMTP. Introduce an optional '--reply-to' command line option. Unfortunately the $reply_to variable name was already taken for the 'In-Reply-To' header field. To reduce code churn, use $reply_address as variable name instead. Signed-off-by: Christian Ludwig --- Documentation/git-send-email.txt | 5 + git-send-email.perl | 18 +- t/t9001-send-email.sh| 2 ++ 3 files changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 8060ea35c..c3bc622b1 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -84,6 +84,11 @@ See the CONFIGURATION section for `sendemail.multiEdit`. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". +--reply-to=:: + Specify the address that replies from reciepients should + to go. Use this if replies to messages should go to another + address than what is specified with the --from parameter. + --in-reply-to=:: Make the first mail (or all the mails with `--no-thread`) appear as a reply to the given Message-Id, which avoids breaking threads to diff --git a/git-send-email.perl b/git-send-email.perl index edcc6d346..fc21081d3 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -56,6 +56,7 @@ git send-email --dump-aliases --[no-]cc * Email Cc: --[no-]bcc* Email Bcc: --subject * Email "Subject:" +--reply-to* Email "Reply-To:" --in-reply-to * Email "In-Reply-To:" --[no-]xmailer * Add "X-Mailer:" header (default). --[no-]annotate* Review each patch that will be sent in an editor. @@ -166,7 +167,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/; # Variables we fill in automatically, or via prompting: my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh, - $initial_reply_to,$initial_subject,@files, + $initial_reply_to,$reply_address,$initial_subject,@files, $author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time); my $envelope_sender; @@ -315,6 +316,7 @@ die __("--dump-aliases incompatible with other options\n") $rc = GetOptions( "sender|from=s" => \$sender, "in-reply-to=s" => \$initial_reply_to, + "reply-to=s" => \$reply_address, "subject=s" => \$initial_subject, "to=s" => \@initial_to, "to-cmd=s" => \$to_cmd, @@ -677,6 +679,7 @@ if ($compose) { my $tpl_sender = $sender || $repoauthor || $repocommitter || ''; my $tpl_subject = $initial_subject || ''; my $tpl_reply_to = $initial_reply_to || ''; + my $tpl_reply_address = $reply_address || ''; print $c < References: +Reply-To: Reply Result: OK EOF @@ -297,6 +298,7 @@ test_expect_success $PREREQ 'Show all headers' ' --dry-run \ --suppress-cc=sob \ --from="Example " \ + --reply-to="Reply " \ --to=t...@example.com \ --cc=c...@example.com \ --bcc=b...@example.com \ -- 2.15.1
Please reply immediately,
Dear Friend, I know that this message will look strange, surprising and probably unbelievable to you, but it is true and reality. I want to transfer the sum of: £35,000,000 (Thirty Five Million British Pounds) to you. THIS IS NOT A JOKE, but after reading if it does not interest you please kindly delete it. I am contacting you by the Will of God. My name is: Mrs. Sarah Faith, I am a British business woman specialized in mining of raw Gold in Africa; but now I am critically sick with esophageal cancer which has damaged almost all the cells in my body system and I will soon die according to my doctors. My late husband died in an accident with our two daughters few years ago leaving me with our only son whom is just 12 years old and he is my most concern now as he is still a child and does not know anything about live and has nobody to take care of him after I am dead; because I and my late husband does not have any relatives, we both grew up in the orphanage home and got married under orphanage as orphans. So if I die now my innocent child would be left alone in this wicked world and I do not wish to send him to any orphanage home, I want him to grow up in the hands of an individual, not orphanage. Please, i am begging you in the name of God to sincerely accept my proposal; let me instruct my bank to wire transfer my fund worth the sum of: £35 MILLION POUNDS to your account in your country immediately, then you take my son to your home and raise him as your own son. Please reply immediately so that we can further discuss the details fast before anything happens to me. Yours Sincerely, Mrs. Sarah Faith.
Urgent reply is needed,
Dear Partner, Please consider this mail serious despite the fact that you did not expect it. Hope you are doing well. I am Mr, Nodian Omera, The Manager of head opérations department of our bank in Burkina Faso. I discovered a risk-free deal of US$9.9 million from my department which was left unclaimed as a result of non existing body.Provided you will put trust forward, let us share the deal if you are interested. Reply to this address;nodian.om...@gmail.com, Urgent reply is needed for more details. Regards, Mr, Nodian Omera,
Please reply, I have a genuine business to discuss with you.
I have a business proposal for you, it is an oil exportation proposition contract for you and this is a highly prospective crude oil sales venture; it involves the exportation 300,000 barrels of Light Crude Oil daily, this project is genuine, legal and highly lucrative. For more details, please reply. Sincerely Hussein Saleh
Reply
I have something very confidential and private to discuss with you
Re: [PATCH] patch reply
I just sent a patch to a new thread which is not what I wanted. However I already sent the same patch a few days ago: https://public-inbox.org/git/CAK7vU=2ePR3jQsgu=rxsmrxytaahqxc0sfrn5yozlzqzp2z...@mail.gmail.com/ 2017-10-17 6:01 GMT+02:00 Junio C Hamano : > Thais Diniz writes: > >> +Just to clarify I did not see Marius patch. >> +Did see Marius' comment saying he would look it in the leftoverbits list, >> +but since i didn't see any patch i thought i could work on it and did so >> based on Stephan's comment >> +(which i suppose Mario also did and that is why the code resulted to be >> similar). > > In any case, both versions share exactly the same "don't call > get_multi() to grab the same configuration values from inside the > callback of git_config()" issue, so whoever works on it to complete > the topic, it needs further work.
Re: [PATCH] patch reply
Thais Diniz writes: > +Just to clarify I did not see Marius patch. > +Did see Marius' comment saying he would look it in the leftoverbits list, > +but since i didn't see any patch i thought i could work on it and did so > based on Stephan's comment > +(which i suppose Mario also did and that is why the code resulted to be > similar). In any case, both versions share exactly the same "don't call get_multi() to grab the same configuration values from inside the callback of git_config()" issue, so whoever works on it to complete the topic, it needs further work.
[PATCH] patch reply
From: Thais Diniz Braz --- emailReply | 4 1 file changed, 4 insertions(+) create mode 100644 emailReply diff --git a/emailReply b/emailReply new file mode 100644 index 0..2d591b55b --- /dev/null +++ b/emailReply @@ -0,0 +1,4 @@ +Just to clarify I did not see Marius patch. +Did see Marius' comment saying he would look it in the leftoverbits list, +but since i didn't see any patch i thought i could work on it and did so based on Stephan's comment +(which i suppose Mario also did and that is why the code resulted to be similar). -- 2.15.0.rc0.39.g2f0e14e.dirty
I am waiting for your Reply
Dear Friend, Good Day. I know this message might meet you in utmost surprise; however, it's just my urgent need for a foreign partner that made me to contact you for this mutual benefiting business when searching for a good and reliable and trust worthy person. I got your contact email address from a Business directory and decided to connect you to this transaction that is based on trust and your understanding. I am Mr.Patrick Joseph I work with the African Development Bank ADB Ouagadougou Burkina-Faso, I would like to know if this proposal will be worthwhile for your acceptance have a Foreign Customer, Paul-Louis Halley from France who was an Investor, Crude Oil Merchant and Federal Government Contractor, he was a victim with Socata TBM 700 killing 6 people crashed on 6 December 2003 near Paris leaving a closing balance of $28.5 Million United States Dollars in one of his Private US dollar Account that was been managed by me as his Customer's Account Officer. Base on my security report, these funds can be claimed without any hitches as no one is aware of the funds and it's closing balance except me and the customer who is (Now Deceased) therefore, I can present you as the Next of Kin and we will work out the modalities for the claiming of the funds in accordance with the law. Now, if you are interested and really sure of your trustworthy, accountability and confidentiality on this transaction without disappointment, you can contact me using my private email, and our sharing ratio will be 50% for me and 40% for you, While 10% will be for the necessary expenses that might occur along the line. I expect your reply. Sincerely, Mr.Patrick Joseph.
Re: Reply Urgent
Hello, How are you doing? We have an inheritance of a deceased client with your surname. Contact Mr Andrew Bailey by this email address: ands...@europe.com with your full names for further information's. Thanks for your understanding. Melissa. -- Correo Corporativo Hospital Universitario del Valle E.S.E *** "Estamos re-dimensionandonos para crecer!" **
REPLY NOW:
Did you receive my previous message about my donation to you? for philanthropic and humanitarian work for all of mankind who are in great need among your friends, family and people around you. REPLY FOR MORE DETAILS. Regards Mrs Mavis Wanczyk.
IMMEDIATE REPLY NEEDED.
Dear, My name is Mr Alaine Kamba, I am the Bill and Exchange (assistant) Manager of Bank of Africa Ouagadougou, Burkina Faso. In my department I discovered an abandoned sum of eighteen million three hundred thousand United State of American dollars (18.3MILLION USA DOLLARS) in an account that belongs to one of our foreign customer who died in airline that crashed on 4th October 2001. Since I got information about his death I have been expecting his next of kin to come over and claim his money because we can not release it unless somebody applies for it as the next of kin or relation to the deceased as indicated in our banking guidelines, but unfortunately we learnt that all his supposed next of kin or relation died alongside with him in the plane crash leaving nobody behind for the claim. It is therefore upon this discovery that I decided to make this business proposal to you and release the money to you as next of kin or relation to the deceased for safety and subsequent disbursement since nobody is coming for it and I don't want the money to go into the bank treasury as unclaimed bill. You will be entitled with 40% of the total sum while 60% will be for me after which I will visit your Country to invest my own share when the fund is successfully transferred into your account, Please I would like you to keep this transaction confidential and as a top secret as you may wish to know that I am a bank official. Yours sincerely, Mr Alaine Kamba.
I Am Mrs Juliana Timothy,i have important thing to discus with you Wating For Your Reply Thanks
I Have A Donation For You
URGENT REPLY FOR MORE DETAILS.
Compliment of the day, I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You. I am aware of the unsafe nature of the internet, and was compelled to use this medium due to the nature of this project. I have access to very vital information that can be used to transfer this huge amount of money. which may culminate into the investment of the said funds into your company or any lucrative venture in your country. If you will like to assist me as a partner then indicate your interest, after which we shall both discuss the modalities and the sharing percentage. Upon receipt of your reply on your expression of Interest I will give you full details, on how the business will be executed I am open for negotiation. Thanks for your anticipated cooperation. Note you might receive this message in your inbox or spam or junk folder, depends on your web host or server network. Regards, Mr.Kere Casmire
URGENT REPLY FOR MORE DETAILS.
Compliment of the day, I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You. I am aware of the unsafe nature of the internet, and was compelled to use this medium due to the nature of this project. I have access to very vital information that can be used to transfer this huge amount of money. which may culminate into the investment of the said funds into your company or any lucrative venture in your country. If you will like to assist me as a partner then indicate your interest, after which we shall both discuss the modalities and the sharing percentage. Upon receipt of your reply on your expression of Interest I will give you full details, on how the business will be executed I am open for negotiation. Thanks for your anticipated cooperation. Note you might receive this message in your inbox or spam or junk folder, depends on your web host or server network. Regards, Mr.Kere Casmire
URGENT REPLY FOR MORE DETAILS.
-- Compliment of the day, I am Mr.Kere Casmire I Have a Business Proposal of $5.3 million For You. I am aware of the unsafe nature of the internet, and was compelled to use this medium due to the nature of this project. I have access to very vital information that can be used to transfer this huge amount of money. which may culminate into the investment of the said funds into your company or any lucrative venture in your country. If you will like to assist me as a partner then indicate your interest, after which we shall both discuss the modalities and the sharing percentage. Upon receipt of your reply on your expression of Interest I will give you full details, on how the business will be executed I am open for negotiation. Thanks for your anticipated cooperation. Note you might receive this message in your inbox or spam or junk folder, depends on your web host or server network. Regards, Mr.Kere Casmire
Urgent reply needed,
Dear Partner, Please consider this mail serious despite the fact that you did not expect it. Hope you are doing well. I am Mr.Alimuji Gabratai, the Manager of head opérations department of our bank in Burkina Faso. I discovered a risk-free deal of US$9.9 million from my department which was left unclaimed as a result of non existing body.Provided you will put trust forward, let us share the deal if you are interested. Urgent reply is needed for more details.Reply to: amuji...@gmail.com, Regards, Mr.Alimuji Gabratai,
Re: My Second Email to You, Pls Reply Me
Hello Dear, How are you doing? I hope you are doing well. I am writing as I have written to you previously without any response from you. I hope all is well with you.I will appreciate if you will acknowledge your receipt of this mail. Thank you and have a good day. Miss Naya Please Write Me at My Private e-mail which i used to send you the previous e-mail( sgtmarkd2...@lycos.com ) KILL Mail Shield Gateway scanned
Reply me back!!
I have been trying to reach you
this is urgent reply.
Greetings My Dear Friend, Before I introduce myself, I wish to inform you that this letter is not a hoax mail and I urge you to treat it serious. This letter must come to you as a big surprise, but I believe it is only a day that people meet and become great friends and business partners. Please I want you to read this letter very carefully and I must apologize for barging this message into your mail box without any formal introduction due to the urgency and confidentiality of this business and I know that this message will come to you as a surprise. Please this is not a joke and I will not like you to joke with it ok, MY name is Mr. zaki ibrahim i am working in ADB bank I have ($17.4million Dollars) to transfer to your country and if you are interested get back to me immediately for more details.and i we give you 40% for you and 60% for me ok. Please note; reply me through this email (mrzakiibra...@gmail.com), call me +226 68 25 71 46 Mr. zaki ibrahim. Telex Manager African Development Bank (ADB)
Re: My Second Email to You, Pls Reply Me Soon
Hello Dear, How are you doing? I hope you are doing well. I am writing as I have written to you previously without any response from you. I hope all is well with you.I will appreciate if you will acknowledge your receipt of this mail. Thank you and have a good day. Mrs Fatma. Please Write Me at My Private email which i used to send you the previous email( d...@t-com.me )
KINDLY REPLY URGENTLY
Dear Friend I am contacting you on a business deal of $9,500,000.00 Million United States Dollars, ready for transfer into your own personal account and if we make this claim, we will share it on the ratio of 50% / 50% basis, I would like to assure you that it be 100% risk free and it will be legally backed up with government approval. Once you are interested to transact this business with me, kindly give me your consent response immediately. Hoping to hear from you. My regards, Mr Ibrahim Kabore EMAIL,ibrahim.kab...@hotmail.com
Please i need your urgent and sincere reply
Dear Good day, I sent this mail praying for it to reach you in good health, since I myself are in a very critical health condition in which I sleep every night without knowing if I may be alive to see the next day. I am a widow suffering from long time illness. I have some funds I inherited from my late husband, my Doctor told me recently that I would not last due to the illness. Having known my condition, I decided to donate this fund to a good person that will utilize it the way i am going to instruct herein. I need a very honest person who can claim this money and use it for Charity works, for orphanages, widows and also build schools for less privilege . I accept this decision because I do not have any child who will inherit this money after I die.Please I want your sincerely and urgent answer to know if you will be able to execute this project, and I will give you more information on how the fund will be transferred to your bank account. I am waiting for your reply and my private email address is caronglori...@yahoo.com Thank you, Mrs Gloria
Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required
Johannes Sixt writes: > Am 13.05.2017 um 00:36 schrieb Junio C Hamano: >> Thanks, all three patches look good. Will queue. >> >> Let's merge them to 'next' soonish and eventually down to 'master' >> and 'maint'. > > The patches change translated strings. You should probably wait for an > update of their translations before you release a maintenance version > with these changes. Yup, thanks.
Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required
Am 13.05.2017 um 00:36 schrieb Junio C Hamano: Thanks, all three patches look good. Will queue. Let's merge them to 'next' soonish and eventually down to 'master' and 'maint'. The patches change translated strings. You should probably wait for an update of their translations before you release a maintenance version with these changes. -- Hannes
Re: [PATCH v4 1/3] usability: don't ask questions if no reply is required
Thanks, all three patches look good. Will queue. Let's merge them to 'next' soonish and eventually down to 'master' and 'maint'. Thanks.
[PATCH v4 1/3] usability: don't ask questions if no reply is required
There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following: git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash and then exits. The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished. The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the `yes` program. The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply that they won't handle indeed. That's a source of confusion on UX level. To improve the general usability of the Git suite, the following rule was applied: if the sentence * appears in a non-interactive session * is printed last before exit * is a question addressing the user ("you") the sentence is turned into affirmative and proposes the option. The basic rewording of the question sentences has been extended to other spots found in the source. Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 Signed-off-by: Jean-Noel Avila --- builtin/am.c | 5 +++-- builtin/checkout.c | 5 ++--- help.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..dd60fad1e 100644 --- a/builtin/am.c +++ b/builtin/am.c @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail) } if (is_empty_file(am_path(state, "patch"))) { - printf_ln(_("Patch is empty. Was it split wrong?")); + printf_ln(_("Patch is empty.")); die_user_resolve(state); } @@ -1940,7 +1940,8 @@ static void am_resolve(struct am_state *state) if (unmerged_cache()) { printf_ln(_("You still have unmerged paths in your index.\n" - "Did you forget to use 'git add'?")); + "You should 'git add' each file with resolved conflicts to mark them as such.\n" + "You might run `git rm` on a file to accept \"deleted by them\" for it.")); die_user_resolve(state); } diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..85c04d252 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1286,9 +1286,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) * new_branch && argc > 1 will be caught later. */ if (opts.new_branch && argc == 1) - die(_("Cannot update paths and switch to branch '%s' at the same time.\n" - "Did you intend to checkout '%s' which can not be resolved as commit?"), - opts.new_branch, argv[0]); + die(_("'%s' is not a commit and a branch '%s' cannot be created from it"), + argv[0], opts.new_branch); if (opts.force_detach) die(_("git checkout: --detach does not take a path argument '%s'"), diff --git a/help.c b/help.c index bc6cd19cf..a07f01e6f 100644 --- a/help.c +++ b/help.c @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) if (SIMILAR_ENOUGH(best_similarity)) { fprintf_ln(stderr, - Q_("\nDid you mean this?", - "\nDid you mean one of these?", + Q_("\nThe most similar command is", + "\nThe most similar commands are", n)); for (i = 0; i < n; i++) -- 2.13.0
[PATCH v3 1/3] usability: don't ask questions if no reply is required
There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following: git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash and then exits. The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished. The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the `yes` program. The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply that they won't handle indeed. That's a source of confusion on UX level. To improve the general usability of the Git suite, the following rule was applied: if the sentence * appears in a non-interactive session * is printed last before exit * is a question addressing the user ("you") the sentence is turned into affirmative and proposes the option. The basic rewording of the question sentences has been extended to other spots found in the source. Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 Signed-off-by: Jean-Noel Avila --- builtin/am.c | 5 +++-- builtin/checkout.c | 5 ++--- help.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..dd60fad1e 100644 --- a/builtin/am.c +++ b/builtin/am.c @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail) } if (is_empty_file(am_path(state, "patch"))) { - printf_ln(_("Patch is empty. Was it split wrong?")); + printf_ln(_("Patch is empty.")); die_user_resolve(state); } @@ -1940,7 +1940,8 @@ static void am_resolve(struct am_state *state) if (unmerged_cache()) { printf_ln(_("You still have unmerged paths in your index.\n" - "Did you forget to use 'git add'?")); + "You should 'git add' each file with resolved conflicts to mark them as such.\n" + "You might run `git rm` on a file to accept \"deleted by them\" for it.")); die_user_resolve(state); } diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..85c04d252 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1286,9 +1286,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) * new_branch && argc > 1 will be caught later. */ if (opts.new_branch && argc == 1) - die(_("Cannot update paths and switch to branch '%s' at the same time.\n" - "Did you intend to checkout '%s' which can not be resolved as commit?"), - opts.new_branch, argv[0]); + die(_("'%s' is not a commit and a branch '%s' cannot be created from it"), + argv[0], opts.new_branch); if (opts.force_detach) die(_("git checkout: --detach does not take a path argument '%s'"), diff --git a/help.c b/help.c index bc6cd19cf..a07f01e6f 100644 --- a/help.c +++ b/help.c @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) if (SIMILAR_ENOUGH(best_similarity)) { fprintf_ln(stderr, - Q_("\nDid you mean this?", - "\nDid you mean one of these?", + Q_("\nThe most similar command is", + "\nThe most similar commands are", n)); for (i = 0; i < n; i++) -- 2.13.0
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
On Thu, May 11, 2017 at 12:28 PM, Konstantin Khomoutov wrote: > On Thu, May 11, 2017 at 10:10:05AM +, Kerry, Richard wrote: > > [...] >> > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) >> > > >> > > if (unmerged_cache()) { >> > > printf_ln(_("You still have unmerged paths in your index.\n" >> > > - "Did you forget to use 'git add'?")); >> > > + "You might want to use 'git add' on them.")); >> > >> > This case is *not* an "rhetorical question is the most succinct way to >> > convey >> > the information" situation; I think this rewrite is a definite improvement. >> > "You might want to 'git add' them" may be more succinct, though. >> >> "You might want to use 'git add' on them." It isn't about what you >> *want* to use, it's what you *need* to use, isn't it? And I'm not >> happy about "on them". I'm not sure quite why, but the phrasing seems >> odd. How about "You might need to use 'git add'.", or "You might need >> to use 'git add' first.", or "'git add' needs to be used to add >> files." , or "'git add' needs to be used before any other git command >> may be used.". > > Why not just > > You should run `git add` on each file with resolved conflicts to mark > them as such. > > I'm not an English speaker but IMHO this phrasing concentrates on the > essense of the problem. It's far from being succint, unfortunately. > > I also wonder what to do with "deleted by them" state of certain files > which are also "unmerged" but `git add`-ing them would be a wrong thing > to do if we want to accept the upstream's decision to delete the file. > So maybe something like > > You might run `git rm` on a file to accept "deleted by them" for it. > > appended to the original hint would be good. I think something like this sounds much better. I think being a bit more verbose is good here, if you know how to solve conflicts you just go "oops, forgot", but for confused users who don't know how, it's better to explain things a bit more verbosely.
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
On Thu, May 11, 2017 at 10:10:05AM +, Kerry, Richard wrote: [...] > > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) > > > > > > if (unmerged_cache()) { > > > printf_ln(_("You still have unmerged paths in your index.\n" > > > - "Did you forget to use 'git add'?")); > > > + "You might want to use 'git add' on them.")); > > > > This case is *not* an "rhetorical question is the most succinct way to > > convey > > the information" situation; I think this rewrite is a definite improvement. > > "You might want to 'git add' them" may be more succinct, though. > > "You might want to use 'git add' on them." It isn't about what you > *want* to use, it's what you *need* to use, isn't it? And I'm not > happy about "on them". I'm not sure quite why, but the phrasing seems > odd. How about "You might need to use 'git add'.", or "You might need > to use 'git add' first.", or "'git add' needs to be used to add > files." , or "'git add' needs to be used before any other git command > may be used.". Why not just You should run `git add` on each file with resolved conflicts to mark them as such. I'm not an English speaker but IMHO this phrasing concentrates on the essense of the problem. It's far from being succint, unfortunately. I also wonder what to do with "deleted by them" state of certain files which are also "unmerged" but `git add`-ing them would be a wrong thing to do if we want to accept the upstream's decision to delete the file. So maybe something like You might run `git rm` on a file to accept "deleted by them" for it. appended to the original hint would be good.
RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required
Some more grammar/usage notes . > -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of Junio C Hamano > Sent: Thursday, May 11, 2017 4:16 AM > To: Jean-Noel Avila > Cc: git@vger.kernel.org; rashmipa...@gmail.com > Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is > required > > Jean-Noel Avila writes: > > > diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d > > 100644 > > --- a/builtin/am.c > > +++ b/builtin/am.c > > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const > char *mail) > > } > > > > if (is_empty_file(am_path(state, "patch"))) { > > - printf_ln(_("Patch is empty. Was it split wrong?")); > > + printf_ln(_("Patch is empty. It may have been split wrong.")); > > die_user_resolve(state); > > } > > While I do not belong to "we should feel free to ask rhetorical questions" > camp, I do not mind this particular rewrite. An obvious alternative is just > to > stop the sentence with "Patch is empty." > > At this point in the code, we do not even know why we are seeing an empty > patch, and "perhaps it was incorrectly split" is not a particularly useful > idle > speculation that would help the user who sees it. s/split wrong/split wrongly/ Though the further discussion suggests that part of the phrase might best be removed entirely. > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) > > > > if (unmerged_cache()) { > > printf_ln(_("You still have unmerged paths in your index.\n" > > - "Did you forget to use 'git add'?")); > > + "You might want to use 'git add' on them.")); > > This case is *not* an "rhetorical question is the most succinct way to convey > the information" situation; I think this rewrite is a definite improvement. > "You might want to 'git add' them" may be more succinct, though. "You might want to use 'git add' on them." It isn't about what you *want* to use, it's what you *need* to use, isn't it? And I'm not happy about "on them". I'm not sure quite why, but the phrasing seems odd. How about "You might need to use 'git add'.", or "You might need to use 'git add' first.", or "'git add' needs to be used to add files." , or "'git add' needs to be used before any other git command may be used.". > > diff --git a/builtin/checkout.c b/builtin/checkout.c index > > bfa5419f3..05037b9b6 100644 > > --- a/builtin/checkout.c > > +++ b/builtin/checkout.c > > @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, > const char *prefix) > > */ > > if (opts.new_branch && argc == 1) > > die(_("Cannot update paths and switch to branch '%s' > at the same time.\n" > > - "Did you intend to checkout '%s' which can not be > resolved as commit?"), > > + "'%s' can not be resolved as commit, but it > should."), > I am not sure a firm statement "but it should" is an improvement. > This message is given when the user says: > > $ git checkout -b newone naster > > And "but it should" is appropriate when it is a mistyped "I want to create and > checkout 'newone' branch at the same commit as 'master' > branch", i.e. > > $ git checkout -b newone master > > The reason why the message begins with "Cannot update paths and ..." > is because it could be a mistyped "I want to grab the file 'naster' > out of 'newone' branch", i.e. the user meant to say this: > > $ git checkout newone naster > > IOW, the current error message is hedging its bets, because it does not want > to exclude the possibility that "-b" is there by mistake (as opposed to > 'naster' > is the typo). > > If we ignore that possibility and assume that 'naster' is the typo (iow, the > user did mean "-b"), then your updated message makes sense. But if we > commit to "the user meant -b", we could make the message even more > helpful by being more direct, e.g. > > die("'%s' is not a commit and a branch '%s' cannot be created from > it"
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
Jean-Noel Avila writes: > diff --git a/builtin/am.c b/builtin/am.c > index a95dd8b4e..f5afa438d 100644 > --- a/builtin/am.c > +++ b/builtin/am.c > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const > char *mail) > } > > if (is_empty_file(am_path(state, "patch"))) { > - printf_ln(_("Patch is empty. Was it split wrong?")); > + printf_ln(_("Patch is empty. It may have been split wrong.")); > die_user_resolve(state); > } While I do not belong to "we should feel free to ask rhetorical questions" camp, I do not mind this particular rewrite. An obvious alternative is just to stop the sentence with "Patch is empty." At this point in the code, we do not even know why we are seeing an empty patch, and "perhaps it was incorrectly split" is not a particularly useful idle speculation that would help the user who sees it. > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) > > if (unmerged_cache()) { > printf_ln(_("You still have unmerged paths in your index.\n" > - "Did you forget to use 'git add'?")); > + "You might want to use 'git add' on them.")); This case is *not* an "rhetorical question is the most succinct way to convey the information" situation; I think this rewrite is a definite improvement. "You might want to 'git add' them" may be more succinct, though. > diff --git a/builtin/checkout.c b/builtin/checkout.c > index bfa5419f3..05037b9b6 100644 > --- a/builtin/checkout.c > +++ b/builtin/checkout.c > @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const > char *prefix) >*/ > if (opts.new_branch && argc == 1) > die(_("Cannot update paths and switch to branch '%s' at > the same time.\n" > - "Did you intend to checkout '%s' which can not be > resolved as commit?"), > + "'%s' can not be resolved as commit, but it > should."), I am not sure a firm statement "but it should" is an improvement. This message is given when the user says: $ git checkout -b newone naster And "but it should" is appropriate when it is a mistyped "I want to create and checkout 'newone' branch at the same commit as 'master' branch", i.e. $ git checkout -b newone master The reason why the message begins with "Cannot update paths and ..." is because it could be a mistyped "I want to grab the file 'naster' out of 'newone' branch", i.e. the user meant to say this: $ git checkout newone naster IOW, the current error message is hedging its bets, because it does not want to exclude the possibility that "-b" is there by mistake (as opposed to 'naster' is the typo). If we ignore that possibility and assume that 'naster' is the typo (iow, the user did mean "-b"), then your updated message makes sense. But if we commit to "the user meant -b", we could make the message even more helpful by being more direct, e.g. die("'%s' is not a commit and a branch '%s' cannot be created from it", argv[0], opts.new_branch); > diff --git a/help.c b/help.c > index bc6cd19cf..4658a55c6 100644 > --- a/help.c > +++ b/help.c > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) > > if (SIMILAR_ENOUGH(best_similarity)) { > fprintf_ln(stderr, > -Q_("\nDid you mean this?", > - "\nDid you mean one of these?", > +Q_("\nThe most approaching command is", > + "\nThe most approaching commands are", > n)); With "closest" or "most similar", as others pointed out, I think this may be an improvement. Thanks.
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
On Tue, May 9, 2017 at 10:18 AM, Jean-Noël AVILA wrote: > Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit : >> >> My point was to ensure that where English is used on-screen it should make >> sense, which in this particular case it didn't (a French idiom which, on >> using an automatic translator, didn't make sense in English). The same of >> course applies to other languages used on-screen. >> >> I agree about ensuring that the application doesn't elicit a response that >> it won't, or can't, actually handle. A rhetorical question is fine, so long >> as it is clear that the program won't accept any further input. >> >> Though I don't agree about the issue of the length of words, as presented to >> a non-native speaker. Sometimes a longer word can be very specific in its >> meaning, and can be looked up in a dictionary if the reader is not familiar >> with it. Sometimes using shorter words can result in a less clear meaning, >> or perhaps be an idiomatic usage, which might be missed by a non-native >> speaker. >> > > Thanks. So what's the status of this patch series? I don't buy the idea of > rhetorical HMI. That's a sure way to confuse non-native speakers. Please note > that I kept the questions when there is a following text. Only questions > addressing the user at the end of output have been rephrased. > > For the "do you mean" questions, the proposition would then simply be: "the > most similar command is:" or "the most similar commands are:". > > and then what about the other patches? When you submit patches you can monitor the next "What's cooking" mail for the status. See "ja/do-not..." here: https://public-inbox.org/git/xmqqlgq77pse@gitster.mtv.corp.google.com/ It got picked up for the "pu" branch. You can fetch git.git and see it there. My feedback on the 3: * 1/3: Mostly covered above. I did notice after my last comment that every time gcc wants to suggest you should do something different (e.g. misspelled variable or macro) it'll say "did you mean?" similar to what git does now. While I think this is a rather tragic story of *nix usability ("user gets asked a question, types yes, gets a few GB/s of y as output") the main UX problem is surely that the user in question didn't understand from the terminal output when the program had exited & wasn't interactive anymore. But overall this seems like optimizing for a really obscure edge case at the expense of making the wording more clever. I don't think "did you mean?" will confuse non-native speakers, as the bug report shows the user in question has a reasonable command of English, they're fundimentally confused about how the shell interface works. * 2/3: Looks great, surprised it took so long for someone to remove that cutsey but bad message. * 3/3: I think this partly makes things slightly worse. I.e. now you get a specific error message about refs being missing, after it shows you the entire usage info, so you don't know if you e.g. misspelled a command-line flag or what. I couldn't find any pattern in the existing shell scripts for "print usage with custom message" thoug. >> Regards, >> Richard. >> >> >> >> >> Richard Kerry >> BNCS Engineer, SI SOL Telco & Media Vertical Practice >> T: +44 (0)20 3618 2669 >> M: +44 (0)7812 325518 >> 4 Triton Square, Regent’s Place, London NW1 3HG >> richard.ke...@atos.net >> >> >> This e-mail and the documents attached are confidential and intended solely >> for the addressee; it may also be privileged. If you receive this e-mail in >> error, please notify the sender immediately and destroy it. As its integrity >> cannot be secured on the Internet, the Atos group liability cannot be >> triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> From: Ævar Arnfjörð Bjarmason [ava...@gmail.com] >> Sent: 04 May 2017 10:09 >> To: Kerry, Richard >> Cc: git@vger.kernel.org >> Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is >> required >> >> On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard >> wrote: >> > >> > May I suggest that " The most approaching commands" doesn't make much >> > sense as English (I don't think a comm
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit : > > My point was to ensure that where English is used on-screen it should make > sense, which in this particular case it didn't (a French idiom which, on > using an automatic translator, didn't make sense in English). The same of > course applies to other languages used on-screen. > > I agree about ensuring that the application doesn't elicit a response that it > won't, or can't, actually handle. A rhetorical question is fine, so long as > it is clear that the program won't accept any further input. > > Though I don't agree about the issue of the length of words, as presented to > a non-native speaker. Sometimes a longer word can be very specific in its > meaning, and can be looked up in a dictionary if the reader is not familiar > with it. Sometimes using shorter words can result in a less clear meaning, > or perhaps be an idiomatic usage, which might be missed by a non-native > speaker. > Thanks. So what's the status of this patch series? I don't buy the idea of rhetorical HMI. That's a sure way to confuse non-native speakers. Please note that I kept the questions when there is a following text. Only questions addressing the user at the end of output have been rephrased. For the "do you mean" questions, the proposition would then simply be: "the most similar command is:" or "the most similar commands are:". and then what about the other patches? Thanks > Regards, > Richard. > > > > > Richard Kerry > BNCS Engineer, SI SOL Telco & Media Vertical Practice > T: +44 (0)20 3618 2669 > M: +44 (0)7812 325518 > 4 Triton Square, Regent’s Place, London NW1 3HG > richard.ke...@atos.net > > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Atos group liability cannot be > triggered for the message content. Although the sender endeavours to maintain > a computer virus-free network, the sender does not warrant that this > transmission is virus-free and will not be liable for any damages resulting > from any virus transmitted. > > ____ > From: Ævar Arnfjörð Bjarmason [ava...@gmail.com] > Sent: 04 May 2017 10:09 > To: Kerry, Richard > Cc: git@vger.kernel.org > Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is > required > > On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard > wrote: > > > > May I suggest that " The most approaching commands" doesn't make much sense > > as English (I don't think a command can "approach"). > > Perhaps it should be " The most appropriate commands". > > I had the same concern, saying "appropriate" is IMO also confusing. > The point of this UI is not to point out what you should be running, > which "appropriate" implies, but just "we couldn't find what you > meant, did you mean one of these?". > > I think nothing needs to change here. The whole premise here is that a > program should never ask a question when you can't give an answer, I > think that's nonsense. There's such a thing as a rhetorical question, > and sometimes using that form is the most obvious & succinct way to > put things. > > Which is not to say that phrasing these things as a non-question can't > be better, but the suggestions so far just seem more complex. > > Also keep in mind that a huge part of the user base for git using the > English UI consists of non-native speakers, and when in doubt we > should definitely be picking simpler English like "did you mean?" v.s. > alternatives with >10 character more obscure words. > > > Richard Kerry > > BNCS Engineer, SI SOL Telco & Media Vertical Practice > > > > T: +44 (0)20 3618 2669 > > M: +44 (0)7812 325518 > > Lync: +44 (0) 20 3618 0778 > > Room G300, Stadium House, Wood Lane, London, W12 7TA > > richard.ke...@atos.net > > > > > > > > > > -Original Message- > > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > > Behalf Of Jean-Noel Avila > > Sent: Wednesday, May 03, 2017 10:07 PM > > To: git@vger.kernel.org > > Cc: rashmipa...@gmail.com; Jean-Noel Avila > > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is > > required > > > > There has been a bug report by a corpora
RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required
My point was to ensure that where English is used on-screen it should make sense, which in this particular case it didn't (a French idiom which, on using an automatic translator, didn't make sense in English). The same of course applies to other languages used on-screen. I agree about ensuring that the application doesn't elicit a response that it won't, or can't, actually handle. A rhetorical question is fine, so long as it is clear that the program won't accept any further input. Though I don't agree about the issue of the length of words, as presented to a non-native speaker. Sometimes a longer word can be very specific in its meaning, and can be looked up in a dictionary if the reader is not familiar with it. Sometimes using shorter words can result in a less clear meaning, or perhaps be an idiomatic usage, which might be missed by a non-native speaker. Regards, Richard. Richard Kerry BNCS Engineer, SI SOL Telco & Media Vertical Practice T: +44 (0)20 3618 2669 M: +44 (0)7812 325518 4 Triton Square, Regent’s Place, London NW1 3HG richard.ke...@atos.net This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. From: Ævar Arnfjörð Bjarmason [ava...@gmail.com] Sent: 04 May 2017 10:09 To: Kerry, Richard Cc: git@vger.kernel.org Subject: Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote: > > May I suggest that " The most approaching commands" doesn't make much sense > as English (I don't think a command can "approach"). > Perhaps it should be " The most appropriate commands". I had the same concern, saying "appropriate" is IMO also confusing. The point of this UI is not to point out what you should be running, which "appropriate" implies, but just "we couldn't find what you meant, did you mean one of these?". I think nothing needs to change here. The whole premise here is that a program should never ask a question when you can't give an answer, I think that's nonsense. There's such a thing as a rhetorical question, and sometimes using that form is the most obvious & succinct way to put things. Which is not to say that phrasing these things as a non-question can't be better, but the suggestions so far just seem more complex. Also keep in mind that a huge part of the user base for git using the English UI consists of non-native speakers, and when in doubt we should definitely be picking simpler English like "did you mean?" v.s. alternatives with >10 character more obscure words. > Richard Kerry > BNCS Engineer, SI SOL Telco & Media Vertical Practice > > T: +44 (0)20 3618 2669 > M: +44 (0)7812 325518 > Lync: +44 (0) 20 3618 0778 > Room G300, Stadium House, Wood Lane, London, W12 7TA > richard.ke...@atos.net > > > > > -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf > Of Jean-Noel Avila > Sent: Wednesday, May 03, 2017 10:07 PM > To: git@vger.kernel.org > Cc: rashmipa...@gmail.com; Jean-Noel Avila > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required > > There has been a bug report by a corporate user that stated that "spelling > mistake of stash followed by a yes prints character 'y' > infinite times." > > This analysis was false. When the spelling of a command contains errors, the > git program tries to help the user by providing candidates which are close to > the unexisting command. E.g Git prints the > following: > > git: 'stahs' is not a git command. See 'git --help'. > Did you mean this? > > stash > > and then exits. > > The problem with this hint is that it is not formally indicated as an hint > and the user is in fact encouraged to reply to the question, whereas the Git > command is already finished. > > The user was unlucky enough that it was the command he was looking for, and > replied "yes" on the command line, effectively launching the `yes` program. > > The initial error is that the Git programs, when launched in command-line > mode (without interaction) must not ask questions, because thes
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
Le jeudi 4 mai 2017, 08:52:43 CEST Kerry, Richard a écrit : > > May I suggest that " The most approaching commands" doesn't make much sense > as English (I don't think a command can "approach"). > Perhaps it should be " The most appropriate commands". > > > Regards, > Richard. > Thank you for your proposition. "approaching" is a frenchism doubled with google translate (sorry!). Maybe "similar" would also work.
Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required
On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard wrote: > > May I suggest that " The most approaching commands" doesn't make much sense > as English (I don't think a command can "approach"). > Perhaps it should be " The most appropriate commands". I had the same concern, saying "appropriate" is IMO also confusing. The point of this UI is not to point out what you should be running, which "appropriate" implies, but just "we couldn't find what you meant, did you mean one of these?". I think nothing needs to change here. The whole premise here is that a program should never ask a question when you can't give an answer, I think that's nonsense. There's such a thing as a rhetorical question, and sometimes using that form is the most obvious & succinct way to put things. Which is not to say that phrasing these things as a non-question can't be better, but the suggestions so far just seem more complex. Also keep in mind that a huge part of the user base for git using the English UI consists of non-native speakers, and when in doubt we should definitely be picking simpler English like "did you mean?" v.s. alternatives with >10 character more obscure words. > Richard Kerry > BNCS Engineer, SI SOL Telco & Media Vertical Practice > > T: +44 (0)20 3618 2669 > M: +44 (0)7812 325518 > Lync: +44 (0) 20 3618 0778 > Room G300, Stadium House, Wood Lane, London, W12 7TA > richard.ke...@atos.net > > > > > -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf > Of Jean-Noel Avila > Sent: Wednesday, May 03, 2017 10:07 PM > To: git@vger.kernel.org > Cc: rashmipa...@gmail.com; Jean-Noel Avila > Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required > > There has been a bug report by a corporate user that stated that "spelling > mistake of stash followed by a yes prints character 'y' > infinite times." > > This analysis was false. When the spelling of a command contains errors, the > git program tries to help the user by providing candidates which are close to > the unexisting command. E.g Git prints the > following: > > git: 'stahs' is not a git command. See 'git --help'. > Did you mean this? > > stash > > and then exits. > > The problem with this hint is that it is not formally indicated as an hint > and the user is in fact encouraged to reply to the question, whereas the Git > command is already finished. > > The user was unlucky enough that it was the command he was looking for, and > replied "yes" on the command line, effectively launching the `yes` program. > > The initial error is that the Git programs, when launched in command-line > mode (without interaction) must not ask questions, because these questions > would normally require a user input as a reply while they won't handle > indeed. That's a source of confusion on UX level. > > To improve the general usability of the Git suite, the following rule was > applied: > > if the sentence > * appears in a non-interactive session > * is printed last before exit > * is a question addressing the user ("you") > > the sentence is turned into affirmative and proposes the option. > > The basic rewording of the question sentences has been extended to other > spots found in the source. > > Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 > > Signed-off-by: Jean-Noel Avila > --- > builtin/am.c | 4 ++-- > builtin/checkout.c | 2 +- > help.c | 4 ++-- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644 > --- a/builtin/am.c > +++ b/builtin/am.c > @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const > char *mail) > } > > if (is_empty_file(am_path(state, "patch"))) { > - printf_ln(_("Patch is empty. Was it split wrong?")); > + printf_ln(_("Patch is empty. It may have been split wrong.")); > die_user_resolve(state); > } > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) > > if (unmerged_cache()) { > printf_ln(_("You still have unmerged paths in your index.\n" > - "Did you forget to use 'git add'?")); > + "You might want to use 'git add' on them.")); > die_user_resolve(state); > } > > diff --git a/buil
RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required
May I suggest that " The most approaching commands" doesn't make much sense as English (I don't think a command can "approach"). Perhaps it should be " The most appropriate commands". Regards, Richard. Richard Kerry BNCS Engineer, SI SOL Telco & Media Vertical Practice T: +44 (0)20 3618 2669 M: +44 (0)7812 325518 Lync: +44 (0) 20 3618 0778 Room G300, Stadium House, Wood Lane, London, W12 7TA richard.ke...@atos.net -Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Jean-Noel Avila Sent: Wednesday, May 03, 2017 10:07 PM To: git@vger.kernel.org Cc: rashmipa...@gmail.com; Jean-Noel Avila Subject: [PATCH v2 1/3] usability: don't ask questions if no reply is required There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following: git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash and then exits. The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished. The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the `yes` program. The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level. To improve the general usability of the Git suite, the following rule was applied: if the sentence * appears in a non-interactive session * is printed last before exit * is a question addressing the user ("you") the sentence is turned into affirmative and proposes the option. The basic rewording of the question sentences has been extended to other spots found in the source. Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 Signed-off-by: Jean-Noel Avila --- builtin/am.c | 4 ++-- builtin/checkout.c | 2 +- help.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644 --- a/builtin/am.c +++ b/builtin/am.c @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail) } if (is_empty_file(am_path(state, "patch"))) { - printf_ln(_("Patch is empty. Was it split wrong?")); + printf_ln(_("Patch is empty. It may have been split wrong.")); die_user_resolve(state); } @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) if (unmerged_cache()) { printf_ln(_("You still have unmerged paths in your index.\n" - "Did you forget to use 'git add'?")); + "You might want to use 'git add' on them.")); die_user_resolve(state); } diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) */ if (opts.new_branch && argc == 1) die(_("Cannot update paths and switch to branch '%s' at the same time.\n" - "Did you intend to checkout '%s' which can not be resolved as commit?"), + "'%s' can not be resolved as commit, but it should."), opts.new_branch, argv[0]); if (opts.force_detach) diff --git a/help.c b/help.c index bc6cd19cf..4658a55c6 100644 --- a/help.c +++ b/help.c @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) if (SIMILAR_ENOUGH(best_similarity)) { fprintf_ln(stderr, - Q_("\nDid you mean this?", - "\nDid you mean one of these?", + Q_("\nThe most approaching command is", + "\nThe most approaching commands are", n)); for (i = 0; i < n; i++) -- 2.12.0 Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entiti
[PATCH v2 1/3] usability: don't ask questions if no reply is required
There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following: git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash and then exits. The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished. The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the `yes` program. The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply while they won't handle indeed. That's a source of confusion on UX level. To improve the general usability of the Git suite, the following rule was applied: if the sentence * appears in a non-interactive session * is printed last before exit * is a question addressing the user ("you") the sentence is turned into affirmative and proposes the option. The basic rewording of the question sentences has been extended to other spots found in the source. Requested at https://github.com/git/git-scm.com/issues/999 by rpai1 Signed-off-by: Jean-Noel Avila --- builtin/am.c | 4 ++-- builtin/checkout.c | 2 +- help.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index a95dd8b4e..f5afa438d 100644 --- a/builtin/am.c +++ b/builtin/am.c @@ -1312,7 +1312,7 @@ static int parse_mail(struct am_state *state, const char *mail) } if (is_empty_file(am_path(state, "patch"))) { - printf_ln(_("Patch is empty. Was it split wrong?")); + printf_ln(_("Patch is empty. It may have been split wrong.")); die_user_resolve(state); } @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state) if (unmerged_cache()) { printf_ln(_("You still have unmerged paths in your index.\n" - "Did you forget to use 'git add'?")); + "You might want to use 'git add' on them.")); die_user_resolve(state); } diff --git a/builtin/checkout.c b/builtin/checkout.c index bfa5419f3..05037b9b6 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -1287,7 +1287,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix) */ if (opts.new_branch && argc == 1) die(_("Cannot update paths and switch to branch '%s' at the same time.\n" - "Did you intend to checkout '%s' which can not be resolved as commit?"), + "'%s' can not be resolved as commit, but it should."), opts.new_branch, argv[0]); if (opts.force_detach) diff --git a/help.c b/help.c index bc6cd19cf..4658a55c6 100644 --- a/help.c +++ b/help.c @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) if (SIMILAR_ENOUGH(best_similarity)) { fprintf_ln(stderr, - Q_("\nDid you mean this?", - "\nDid you mean one of these?", + Q_("\nThe most approaching command is", + "\nThe most approaching commands are", n)); for (i = 0; i < n; i++) -- 2.12.0
Re: [PATCH 1/4] usability: don't ask questions if no reply is required
Le mercredi 3 mai 2017, 09:47:44 CEST Jonathan Nieder a écrit : > Hi, > > Jean-Noel Avila wrote: > > As described in the bug report at > > > > https://github.com/git/git-scm.com/issues/999 > > External issue tracker URLs have been known to change or disappear and > we try to make commit messages self-contained instead of relying on > them. It is common to put a 'Requested-by:' footer or sentence saying > 'Requested at by ' near the bottom of a commit message > for attribution and context. Relying on the bug report more heavily > like this example (instead of including any relevant information) > makes it harder for a reader to understand the patch easily in > one place. > > In other words, instead of asking the reader to read the bug report, > please include pertinent information the reader needs to > understand the patch here so they don't have to. Ok. Will include more context in the commit message and just provide the BT as an additional link. > > > the user was disconcerted by the question asked by the program not > > requiring a reply from the user. To improve the general usability of > > the Git suite, The following rule was applied: > > > > if the sentence > > > > * appears in a non-interactive session > > * is printed last before exit > > * is a question addressing the user ("you") > > > > the sentence is turned into affirmative and proposes the option. > > > > Signed-off-by: Jean-Noel Avila > > --- > > > > help.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/help.c b/help.c > > index bc6cd19cf..4658a55c6 100644 > > --- a/help.c > > +++ b/help.c > > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) > > > > if (SIMILAR_ENOUGH(best_similarity)) { > > > > fprintf_ln(stderr, > > > > - Q_("\nDid you mean this?", > > - "\nDid you mean one of these?", > > + Q_("\nThe most approaching command is", > > + "\nThe most approaching commands are", > > > >n)); > > For what it's worth, I find the new text harder to understand than the > old text. > > From the bug report: > > Now git says git: 'stahs' is not a git command. See 'git --help'. > Did you mean this? > > stash > > Git asked if i meant git stash. and i entered yes. and git > printed the character y infinite times. > > If I'm reading that correctly, the problem is not that questions are > alarming but that Git did not cope well with the answer. When I try > to reproduce it, I get No, I don't think that the questions are alarming. The whole point is that Git no longer runs when the user enters its reply. In the case of the bug report, the user was unlucky to type in the name of the shell command `yes` because he was thinking that Git was still running interactively, due to the question at the end of the run. So this patch series'aim is simply to get rid of asking questions just before exiting. Even if a question might seem more user friendly, it's insufficiently formal to indicate to the user that there's no point replying. The question was just a hint, and it should presented as such. To be fair, I'm not accustomed enough to the code to know exactly in which cases the given strings are occurring (except here). All the patch series tries to tackle this at different levels. Maybe squashing them all would be better for understanding. > > $ git stahs > WARNING: You called a Git command named 'stahs', which does not exist. > Continuing under the assumption that you meant 'stash' > in 5.0 seconds automatically... > > which is much clearer. After commenting out "[help] autocorrect = 50" in my > ~/.config/git/config, I get > > $ git stahs > git: 'stahs' is not a git command. See 'git --help'. > > Did you mean this? > stash > > which does seem improvable, at least for consistency with the > autocorrect case. For example, would something like > > $ git stahs > fatal: You called a Git command named 'stahs', which does not exist. > hint: Did you mean 'git stash'? > > work better? And the autocorrect case could say something like Would adding a "hint:" prefix be enough to provide context? I don't think so. I'd prefer to be clearer on the objectives of the printed information, even at the risk of being clumsy. > > $ git stahs > warning: You called a Git command named 'stahs', which does not exist. > warning: Continuing under the assumption that you meant 'stash' > warning: in 5.0 seconds automatically... > > Is contact information for the bug reporter available so we can try out > different wordings and see what works for them? I guess so. The discussion on github is still open and only depends on the willingness of the reporter to reply. > > Thanks and hope that helps, > Jonathan
Re: [PATCH 1/4] usability: don't ask questions if no reply is required
+cc rashmipa...@gmail.com On Wed, May 3, 2017 at 9:47 AM, Jonathan Nieder wrote: > Hi, > > Jean-Noel Avila wrote: > >> As described in the bug report at >> >> https://github.com/git/git-scm.com/issues/999 > > External issue tracker URLs have been known to change or disappear and > we try to make commit messages self-contained instead of relying on > them. It is common to put a 'Requested-by:' footer or sentence saying > 'Requested at by ' near the bottom of a commit message > for attribution and context. Relying on the bug report more heavily > like this example (instead of including any relevant information) > makes it harder for a reader to understand the patch easily in > one place. > > In other words, instead of asking the reader to read the bug report, > please include pertinent information the reader needs to > understand the patch here so they don't have to. > >> the user was disconcerted by the question asked by the program not >> requiring a reply from the user. To improve the general usability of >> the Git suite, The following rule was applied: >> >> if the sentence >> * appears in a non-interactive session >> * is printed last before exit >> * is a question addressing the user ("you") >> >> the sentence is turned into affirmative and proposes the option. >> >> Signed-off-by: Jean-Noel Avila >> --- >> help.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/help.c b/help.c >> index bc6cd19cf..4658a55c6 100644 >> --- a/help.c >> +++ b/help.c >> @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) >> >> if (SIMILAR_ENOUGH(best_similarity)) { >> fprintf_ln(stderr, >> -Q_("\nDid you mean this?", >> - "\nDid you mean one of these?", >> +Q_("\nThe most approaching command is", >> + "\nThe most approaching commands are", >> n)); > > For what it's worth, I find the new text harder to understand than the > old text. > > From the bug report: > > Now git says git: 'stahs' is not a git command. See 'git --help'. > Did you mean this? > > stash > > Git asked if i meant git stash. and i entered yes. and git > printed the character y infinite times. > > If I'm reading that correctly, the problem is not that questions are > alarming but that Git did not cope well with the answer. When I try > to reproduce it, I get > > $ git stahs > WARNING: You called a Git command named 'stahs', which does not exist. > Continuing under the assumption that you meant 'stash' > in 5.0 seconds automatically... > > which is much clearer. After commenting out "[help] autocorrect = 50" in my > ~/.config/git/config, I get > > $ git stahs > git: 'stahs' is not a git command. See 'git --help'. > > Did you mean this? > stash > > which does seem improvable, at least for consistency with the > autocorrect case. For example, would something like > > $ git stahs > fatal: You called a Git command named 'stahs', which does not exist. > hint: Did you mean 'git stash'? > > work better? And the autocorrect case could say something like > > $ git stahs > warning: You called a Git command named 'stahs', which does not exist. > warning: Continuing under the assumption that you meant 'stash' > warning: in 5.0 seconds automatically... > > Is contact information for the bug reporter available so we can try out > different wordings and see what works for them? yes, cc'd. Also see https://public-inbox.org/git/caoqcaxsozcg8mijv+yattmc1pfgyiosqtrasdbhbp2rrhbo...@mail.gmail.com > > Thanks and hope that helps, > Jonathan
Re: [PATCH 1/4] usability: don't ask questions if no reply is required
Hi, Jean-Noel Avila wrote: > As described in the bug report at > > https://github.com/git/git-scm.com/issues/999 External issue tracker URLs have been known to change or disappear and we try to make commit messages self-contained instead of relying on them. It is common to put a 'Requested-by:' footer or sentence saying 'Requested at by ' near the bottom of a commit message for attribution and context. Relying on the bug report more heavily like this example (instead of including any relevant information) makes it harder for a reader to understand the patch easily in one place. In other words, instead of asking the reader to read the bug report, please include pertinent information the reader needs to understand the patch here so they don't have to. > the user was disconcerted by the question asked by the program not > requiring a reply from the user. To improve the general usability of > the Git suite, The following rule was applied: > > if the sentence > * appears in a non-interactive session > * is printed last before exit > * is a question addressing the user ("you") > > the sentence is turned into affirmative and proposes the option. > > Signed-off-by: Jean-Noel Avila > --- > help.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/help.c b/help.c > index bc6cd19cf..4658a55c6 100644 > --- a/help.c > +++ b/help.c > @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) > > if (SIMILAR_ENOUGH(best_similarity)) { > fprintf_ln(stderr, > -Q_("\nDid you mean this?", > - "\nDid you mean one of these?", > +Q_("\nThe most approaching command is", > + "\nThe most approaching commands are", > n)); For what it's worth, I find the new text harder to understand than the old text. >From the bug report: Now git says git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash Git asked if i meant git stash. and i entered yes. and git printed the character y infinite times. If I'm reading that correctly, the problem is not that questions are alarming but that Git did not cope well with the answer. When I try to reproduce it, I get $ git stahs WARNING: You called a Git command named 'stahs', which does not exist. Continuing under the assumption that you meant 'stash' in 5.0 seconds automatically... which is much clearer. After commenting out "[help] autocorrect = 50" in my ~/.config/git/config, I get $ git stahs git: 'stahs' is not a git command. See 'git --help'. Did you mean this? stash which does seem improvable, at least for consistency with the autocorrect case. For example, would something like $ git stahs fatal: You called a Git command named 'stahs', which does not exist. hint: Did you mean 'git stash'? work better? And the autocorrect case could say something like $ git stahs warning: You called a Git command named 'stahs', which does not exist. warning: Continuing under the assumption that you meant 'stash' warning: in 5.0 seconds automatically... Is contact information for the bug reporter available so we can try out different wordings and see what works for them? Thanks and hope that helps, Jonathan
[PATCH 1/4] usability: don't ask questions if no reply is required
As described in the bug report at https://github.com/git/git-scm.com/issues/999 the user was disconcerted by the question asked by the program not requiring a reply from the user. To improve the general usability of the Git suite, The following rule was applied: if the sentence * appears in a non-interactive session * is printed last before exit * is a question addressing the user ("you") the sentence is turned into affirmative and proposes the option. Signed-off-by: Jean-Noel Avila --- help.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/help.c b/help.c index bc6cd19cf..4658a55c6 100644 --- a/help.c +++ b/help.c @@ -411,8 +411,8 @@ const char *help_unknown_cmd(const char *cmd) if (SIMILAR_ENOUGH(best_similarity)) { fprintf_ln(stderr, - Q_("\nDid you mean this?", - "\nDid you mean one of these?", + Q_("\nThe most approaching command is", + "\nThe most approaching commands are", n)); for (i = 0; i < n; i++) -- 2.12.0
Please reply ASAP (For Alex)
Dear Friend, I want to introduce my self to you. I am Mr. Alex Lee a banker. I work in a bank here in Seoul, Korea. I have been the account officer to most Koreans government official till date. I discovered a Dormant account with a lot of money. I need your bank account to transfer the money for our mutual benefit. For your assistance as the account owner we shall share the funds equally. If interested contact me through email for more details. My email address is: mralexlee7...@gmail.com Please reply ASAP. Mr. Alex Lee.
Re:GOOD DAY AND URGENT REPLY.
MY name is Mr. ahmed zongo i am working in ADB bank I have ($17.4million Dollars) to transfer to your country and if you are interested get back to me immediately for more details.and i we give 40% for you and 60% for me ok. Please note; reply me through this email (zongoahmed...@gmail.com), call me +226 68 25 71 46 1) Your full name (2) Your age (3)Your occupation (4)Your marital status (5)Your full residential address and country. (6)Your direct phone and fax numbers. (7)A copy of your driving license or passport scanned and sent to me by mail. Mr. Ahmed Zongo. Telex Manager African Development Bank (ADB) call me +226 68 25 71 46
Re: [RFC] send-email: avoid duplicate In-Reply-To and References headers
Eric Wong writes: > Junio C Hamano wrote: >> >> I think it is sensibleto give priority to the --in-reply-to option >> given from the command line over the in-file one. I am not sure if >> we want to drop references, though. Wouldn't it make more sense to >> just add what we got from the command line to what we read from the >> file? I dunno. > > You're right, existing References in the bodies should probably > be prepended to current ones, as their order should be > oldest-to-newest. If you were to go that way, it may also make sense to demote the original In-Reply-To you find in the file to an entry in the References list, if it does not already appear there. I didn't check the RFCs, but I think your original motivation is to ensure that there is not more than one messages to which the current message is replying to, iow, to ensure that there is only one message that is In-Reply-To, so appending would not be a good solution there.
Re: [RFC] send-email: avoid duplicate In-Reply-To and References headers
Junio C Hamano wrote: > Eric Wong writes: > > When parsing an mbox, it is possible to get existing In-Reply-To > > and References headers blindly appended into the headers of > > message we generate. This is probably the wrong thing to do > > and we should prioritize what was given in the command-line, > > cover letter, and previously-sent messages. > > > > One example I've noticed in the wild was: > > > > https://public-inbox.org/git/2016124541.8216-17-vascomalme...@sapo.pt/raw > > --- > > I'm not completely sure this is what Vasco was doing in that > > message, so it's an RFC for now... > > I think it is sensibleto give priority to the --in-reply-to option > given from the command line over the in-file one. I am not sure if > we want to drop references, though. Wouldn't it make more sense to > just add what we got from the command line to what we read from the > file? I dunno. You're right, existing References in the bodies should probably be prepended to current ones, as their order should be oldest-to-newest. I'll wait on comments a bit and work on a better version w/ tests next week.
Re: [RFC] send-email: avoid duplicate In-Reply-To and References headers
Eric Wong writes: > When parsing an mbox, it is possible to get existing In-Reply-To > and References headers blindly appended into the headers of > message we generate. This is probably the wrong thing to do > and we should prioritize what was given in the command-line, > cover letter, and previously-sent messages. > > One example I've noticed in the wild was: > > https://public-inbox.org/git/2016124541.8216-17-vascomalme...@sapo.pt/raw > --- > I'm not completely sure this is what Vasco was doing in that > message, so it's an RFC for now... I think it is sensibleto give priority to the --in-reply-to option given from the command line over the in-file one. I am not sure if we want to drop references, though. Wouldn't it make more sense to just add what we got from the command line to what we read from the file? I dunno. > git-send-email.perl | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/git-send-email.perl b/git-send-email.perl > index 068d60b3e6..5ab3d8585c 100755 > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -1543,7 +1543,13 @@ foreach my $t (@files) { > elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) { > push @xh, $_; > } > - > + elsif (/^(?:References|In-Reply-To):/i) { > + if (defined $initial_reply_to || $thread) { > + warn > +"Ignoring $_ header in mbox body since it conflicts with\n > +--in-reply-to and --thread switches\n" > + } > + } > } else { > # In the traditional > # "send lots of email" format,
[RFC] send-email: avoid duplicate In-Reply-To and References headers
When parsing an mbox, it is possible to get existing In-Reply-To and References headers blindly appended into the headers of message we generate. This is probably the wrong thing to do and we should prioritize what was given in the command-line, cover letter, and previously-sent messages. One example I've noticed in the wild was: https://public-inbox.org/git/2016124541.8216-17-vascomalme...@sapo.pt/raw --- I'm not completely sure this is what Vasco was doing in that message, so it's an RFC for now... git-send-email.perl | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl index 068d60b3e6..5ab3d8585c 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1543,7 +1543,13 @@ foreach my $t (@files) { elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) { push @xh, $_; } - + elsif (/^(?:References|In-Reply-To):/i) { + if (defined $initial_reply_to || $thread) { + warn +"Ignoring $_ header in mbox body since it conflicts with\n +--in-reply-to and --thread switches\n" + } + } } else { # In the traditional # "send lots of email" format, -- EW
REPLY NOW
We have an inheritance of a deceased client with your surname. Kindly contact Andrew Bailey via email with your full Names and address. ( baanidle...@hotmail.com )for more info. -- Correo Corporativo Hospital Universitario del Valle E.S.E *** "Estamos re-dimensionandonos para crecer!" **
Please reply me
My dear friend, I am Mrs Rebecca Taylor from Kuwait married to Late Mr. Alfred Taylor from Ivory Coast West Africa, of paroisse saint sebastien Church. I and My late husband has done numerous charity service within and outside our region since 1981. We have been doing our best to promote charity work anywhere the Lord laid us to. Since His death I have been having Lung Cancer and now my doctor has confirm to me that i would not last for the next 16 Weeks due to the cancer illness. My husband died as the result of a Political tussle in Cote d' Ivoire 2011 that took many innocent lives between the former president Laurent Gbago and President Alassane Ouattara. I have been distributing all i have since the Doctor gave me the notification and I also want to entrust the sum of Six Million Five hundred thousand U.S Dollars to your care so that you can use it for charity services in your area to the Glory of God and Service to humanity. I will be waiting to hear from you and receive your assurance to be able to fulfill this charity work in your area in sincerity and good will. Yours sincerely sister Rebecca Taylor
I will be waiting for your reply
Hello, My name is Chan Chak a bank manager with an investment bank, I have a business deal of mutual benefit that involve transfer of large sum of money. Get back to me through my private email:- chanch...@gmail.com for more details if you are interested. CHAN CHAK -- 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: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields
On 06/09/2016 11:45 AM, Matthieu Moy wrote: Samuel GROOT writes: diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index edbba3a..21776f0 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". ---in-reply-to=:: +--in-reply-to=:: Make the first mail (or all the mails with `--no-thread`) appear as a - reply to the given Message-Id, which avoids breaking threads to - provide a new patch series. + reply to the given Message-Id (given directly by argument or via the email + file), which avoids breaking threads to provide a new patch series. The second and subsequent emails will be sent as replies according to the `--[no]-chain-reply-to` setting. + +Furthermore, if the argument is an email file, parse it and populate header +fields appropriately for the reply. "populate header fields appropriately" would seem obscure to someone not having followed this converation. At least s/fields/To: and Cc: fields/. We weren't sure how precise the documentation had to be, and tried to keep it concise. --- a/git-send-email.perl +++ b/git-send-email.perl @@ -55,6 +55,7 @@ git send-email --dump-aliases --[no-]bcc* Email Bcc: --subject * Email "Subject:" --in-reply-to * Email "In-Reply-To:" +--in-reply-to* Populate header fields appropriately. Likewise. To avoid an overly long line, I'd write just "Populate To/Cc/In-reply-to". Probably should be . Thanks, will do in v5. +if ($initial_reply_to && -f $initial_reply_to) { + my $error = validate_patch($initial_reply_to); + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n" + if $error; + + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to"; + my $mail = Git::parse_email($fh); + close $fh; + + my $initial_sender = $sender || $repoauthor || $repocommitter || ''; This is duplicated from the "if ($compose) { ... my $tpl_sender = ..." a bit later in the existing file. It would be better to get this "my $initial_sender = ..." out of your "if" and use $initial_sender directly later IMHO. Actually, $initial_sender does not seem to be a good variable name. It's not really "initial", right? $sender looks like a better name, I will work on that, thanks! + my $prefix_re = ""; + my $subject_re = $mail->{"subject"}[0]; + if ($subject_re =~ /^[^Re:]/) { + $prefix_re = "Re: "; + } + $initial_subject = $prefix_re . $subject_re; Why introduce $prefix_re. You can just my $subject = $mail->{"subject"}[0]; if (...) { $subject = "Re: " . $subject; } (preferably using sensible as '...' as noted by Junio ;-) ). I will keep Junio's suggestion :-) In previous iterations of this series, you had issues with non-ascii characters in at least To: and Cc: fields (perhaps in the Subject field too?). Are they solved? I don't see any tests about it ... Non-ascii characters are still an issue, I will work on that next week. -- 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: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields
On 06/08/2016 08:23 PM, Junio C Hamano wrote: Samuel GROOT writes: +if ($initial_reply_to && -f $initial_reply_to) { + my $error = validate_patch($initial_reply_to); This call is wrong, isn't it? You are not going to send out the message you are responding to (the message may not even be a patch), and you do not want to die with an error message that says "patch contains an overlong line". We used to handle email files like patch files (with Cc:, To:, From:, ... fields, a patch is almost an email, with some trailers). But that `validate_patch` subroutine call is indeed useless here, I will remove it. + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n" + if $error; + + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to"; + my $mail = Git::parse_email($fh); + close $fh; my $header = Git::parse_email_header($fh); perhaps? Git::parse_email will be renamed into Git::parse_email_header in v5. + my $initial_sender = $sender || $repoauthor || $repocommitter || ''; + + my $prefix_re = ""; + my $subject_re = $mail->{"subject"}[0]; + if ($subject_re =~ /^[^Re:]/) { + $prefix_re = "Re: "; + } + $initial_subject = $prefix_re . $subject_re; I am not sure what the significance of the fact that the subject happens to begin with a letter other than 'R', 'e', or ':'. Did you mean to do something like this instead? my $subject = $mail->{"subject"}[0]; $subject =~ s/^(re:\s*)+//i; # strip "Re: Re: ..." $initial_subject = "Re: $subject"; instead? That's way cleaner, thanks! By the way, this is a good example why your "unfold" implementation in 4/6 is unwieldy for the caller. Imagine a rather long subject that is folded, i.e. To: Samuel Subject: Help! I am having a trouble running git-send-email correctly. Message-id: <...> It's a good point. What you suggested in 4/6 reply will be used in v5. -- 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: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields
Samuel GROOT writes: > diff --git a/Documentation/git-send-email.txt > b/Documentation/git-send-email.txt > index edbba3a..21776f0 100644 > --- a/Documentation/git-send-email.txt > +++ b/Documentation/git-send-email.txt > @@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'. > the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not > set, as returned by "git var -l". > > ---in-reply-to=:: > +--in-reply-to=:: > Make the first mail (or all the mails with `--no-thread`) appear as a > - reply to the given Message-Id, which avoids breaking threads to > - provide a new patch series. > + reply to the given Message-Id (given directly by argument or via the > email > + file), which avoids breaking threads to provide a new patch series. > The second and subsequent emails will be sent as replies according to > the `--[no]-chain-reply-to` setting. > + > +Furthermore, if the argument is an email file, parse it and populate header > +fields appropriately for the reply. "populate header fields appropriately" would seem obscure to someone not having followed this converation. At least s/fields/To: and Cc: fields/. > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -55,6 +55,7 @@ git send-email --dump-aliases > --[no-]bcc* Email Bcc: > --subject * Email "Subject:" > --in-reply-to * Email "In-Reply-To:" > +--in-reply-to* Populate header fields appropriately. Likewise. To avoid an overly long line, I'd write just "Populate To/Cc/In-reply-to". Probably should be . > +if ($initial_reply_to && -f $initial_reply_to) { > + my $error = validate_patch($initial_reply_to); > + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n" > + if $error; > + > + open my $fh, "<", $initial_reply_to or die "can't open file > $initial_reply_to"; > + my $mail = Git::parse_email($fh); > + close $fh; > + > + my $initial_sender = $sender || $repoauthor || $repocommitter || ''; This is duplicated from the "if ($compose) { ... my $tpl_sender = ..." a bit later in the existing file. It would be better to get this "my $initial_sender = ..." out of your "if" and use $initial_sender directly later IMHO. Actually, $initial_sender does not seem to be a good variable name. It's not really "initial", right? > + my $prefix_re = ""; > + my $subject_re = $mail->{"subject"}[0]; > + if ($subject_re =~ /^[^Re:]/) { > + $prefix_re = "Re: "; > + } > + $initial_subject = $prefix_re . $subject_re; Why introduce $prefix_re. You can just my $subject = $mail->{"subject"}[0]; if (...) { $subject = "Re: " . $subject; } (preferably using sensible as '...' as noted by Junio ;-) ). In previous iterations of this series, you had issues with non-ascii characters in at least To: and Cc: fields (perhaps in the Subject field too?). Are they solved? I don't see any tests about it ... -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields
Samuel GROOT writes: > +if ($initial_reply_to && -f $initial_reply_to) { > + my $error = validate_patch($initial_reply_to); This call is wrong, isn't it? You are not going to send out the message you are responding to (the message may not even be a patch), and you do not want to die with an error message that says "patch contains an overlong line". > + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n" > + if $error; > + > + open my $fh, "<", $initial_reply_to or die "can't open file > $initial_reply_to"; > + my $mail = Git::parse_email($fh); > + close $fh; my $header = Git::parse_email_header($fh); perhaps? > + my $initial_sender = $sender || $repoauthor || $repocommitter || ''; > + > + my $prefix_re = ""; > + my $subject_re = $mail->{"subject"}[0]; > + if ($subject_re =~ /^[^Re:]/) { > + $prefix_re = "Re: "; > + } > + $initial_subject = $prefix_re . $subject_re; I am not sure what the significance of the fact that the subject happens to begin with a letter other than 'R', 'e', or ':'. Did you mean to do something like this instead? my $subject = $mail->{"subject"}[0]; $subject =~ s/^(re:\s*)+//i; # strip "Re: Re: ..." $initial_subject = "Re: $subject"; instead? By the way, this is a good example why your "unfold" implementation in 4/6 is unwieldy for the caller. Imagine a rather long subject that is folded, i.e. To: Samuel Subject: Help! I am having a trouble running git-send-email correctly. Message-id: <...> -- 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
[PATCH v4 5/6] send-email: --in-reply-to= populate header fields
Take an email message file, parse it and fill the "From", "To", "Cc", "In-reply-to", "References" fields appropriately. If `--compose` option is set, it will also fill the subject field with `Re: ['s subject]` in the introductory message. Signed-off-by: Tom RUSSELLO Signed-off-by: Samuel GROOT Signed-off-by: Matthieu MOY --- Documentation/git-send-email.txt | 9 +++-- git-send-email.perl | 51 +++- t/t9001-send-email.sh| 83 3 files changed, 138 insertions(+), 5 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index edbba3a..21776f0 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". ---in-reply-to=:: +--in-reply-to=:: Make the first mail (or all the mails with `--no-thread`) appear as a - reply to the given Message-Id, which avoids breaking threads to - provide a new patch series. + reply to the given Message-Id (given directly by argument or via the email + file), which avoids breaking threads to provide a new patch series. The second and subsequent emails will be sent as replies according to the `--[no]-chain-reply-to` setting. + +Furthermore, if the argument is an email file, parse it and populate header +fields appropriately for the reply. ++ So for example when `--thread` and `--no-chain-reply-to` are specified, the second and subsequent patches will be replies to the first one like in the illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`: diff --git a/git-send-email.perl b/git-send-email.perl index 9b51062..b444ea6 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -55,6 +55,7 @@ git send-email --dump-aliases --[no-]bcc * Email Bcc: --subject * Email "Subject:" --in-reply-to * Email "In-Reply-To:" +--in-reply-to* Populate header fields appropriately. --[no-]xmailer * Add "X-Mailer:" header (default). --[no-]annotate* Review each patch that will be sent in an editor. --compose * Open an editor for introduction. @@ -160,7 +161,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/; # Variables we fill in automatically, or via prompting: my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh, - $initial_reply_to,$initial_subject,@files, + $initial_reply_to,$initial_references,$initial_subject,@files, $author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time); my $envelope_sender; @@ -639,6 +640,52 @@ if (@files) { usage(); } +if ($initial_reply_to && -f $initial_reply_to) { + my $error = validate_patch($initial_reply_to); + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n" + if $error; + + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to"; + my $mail = Git::parse_email($fh); + close $fh; + + my $initial_sender = $sender || $repoauthor || $repocommitter || ''; + + my $prefix_re = ""; + my $subject_re = $mail->{"subject"}[0]; + if ($subject_re =~ /^[^Re:]/) { + $prefix_re = "Re: "; + } + $initial_subject = $prefix_re . $subject_re; + + push @initial_to, $mail->{"from"}[0]; + + foreach my $to_addr (parse_address_line(join ",", @{$mail->{"to"}})) { + if (!($to_addr eq $initial_sender)) { + push @initial_cc, $to_addr; + } + } + + if (defined $mail->{"cc"}) { + foreach my $cc_addr (parse_address_line(join ",", @{$mail->{"cc"}})) { + my $qaddr = unquote_rfc2047($cc_addr); + my $saddr = sanitize_address($qaddr); + if ($saddr eq $initial_sender) { + next if ($suppress_cc{'self'}); + } else { + next if ($suppress_cc{'cc'}); + } + push @initial_cc, $cc_addr; + } + } + + $initial_reply_to = $mail->{"message-id"}[0]; + if ($mail->{"references"}) { + $initial_references = join("", @{$mail->{"references"}}) . + &
[PATCH v3 5/6] send-email: --in-reply-to= populates the fields
Take an email message file, parse it and fill the "From", "To", "Cc", "In-reply-to", "References" fields appropriately. If `--compose` option is set, it will also fill the subject field with `Re: ['s subject]` in the introductory message. Signed-off-by: Tom RUSSELLO Signed-off-by: Samuel GROOT Signed-off-by: Matthieu MOY --- Check if the string given by argument with `--in-reply-to` leads to an existing plain text file. If not, consider it as a message-id. Changes sinces v2: - Fill the References: field to keep the thread even if some emails have been removed - Explicit error with a proper "if" when an error occured during email file opening - More precise comments - More tests Documentation/git-send-email.txt | 9 +++-- git-send-email.perl | 49 +++- t/t9001-send-email.sh| 83 3 files changed, 136 insertions(+), 5 deletions(-) diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index edbba3a..21776f0 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'. the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by "git var -l". ---in-reply-to=:: +--in-reply-to=:: Make the first mail (or all the mails with `--no-thread`) appear as a - reply to the given Message-Id, which avoids breaking threads to - provide a new patch series. + reply to the given Message-Id (given directly by argument or via the email + file), which avoids breaking threads to provide a new patch series. The second and subsequent emails will be sent as replies according to the `--[no]-chain-reply-to` setting. + +Furthermore, if the argument is an email file, parse it and populate header +fields appropriately for the reply. ++ So for example when `--thread` and `--no-chain-reply-to` are specified, the second and subsequent patches will be replies to the first one like in the illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`: diff --git a/git-send-email.perl b/git-send-email.perl index db114ae..66aa2cd 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -55,6 +55,7 @@ git send-email --dump-aliases --[no-]bcc * Email Bcc: --subject * Email "Subject:" --in-reply-to * Email "In-Reply-To:" +--in-reply-to* Populate header fields appropriately. --[no-]xmailer * Add "X-Mailer:" header (default). --[no-]annotate* Review each patch that will be sent in an editor. --compose * Open an editor for introduction. @@ -160,7 +161,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/; # Variables we fill in automatically, or via prompting: my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh, - $initial_reply_to,$initial_subject,@files, + $initial_reply_to,$initial_references,$initial_subject,@files, $author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time); my $envelope_sender; @@ -639,6 +640,50 @@ if (@files) { usage(); } +if ($initial_reply_to && -f $initial_reply_to) { + my $error = validate_patch($initial_reply_to); + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n" + if $error; + + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to"; + my $mail = parse_email($fh); + close $fh; + + my $initial_sender = $sender || $repoauthor || $repocommitter || ''; + + my $prefix_re = ""; + my $subject_re = $mail->{"subject"}[0]; + if ($subject_re =~ /^[^Re:]/) { + $prefix_re = "Re: "; + } + $initial_subject = $prefix_re . $subject_re; + + push @initial_to, $mail->{"from"}[0]; + + foreach my $to_addr (parse_address_line(join ",", @{$mail->{"to"}})) { + if (!($to_addr eq $initial_sender)) { + push @initial_cc, $to_addr; + } + } + + foreach my $cc_addr (parse_address_line(join ",", @{$mail->{"cc"}})) { + my $qaddr = unquote_rfc2047($cc_addr); + my $saddr = sanitize_address($qaddr); + if ($saddr eq $initial_sender) { + next if ($suppress_cc{'self'}); + } else { + next if ($suppress_cc{'cc'}); + } + push @ini
Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Samuel GROOT writes: > On 05/25/2016 08:31 PM, Matthieu Moy wrote: >> So, a possible UI would be: >> >> git send-email --in-reply-to= => just set In-Reply-To: field. >> >> git send-email --in-reply-to= => set In-Reply-To, To and Cc. >> >> git send-email --in-reply-to= --cite => in addition, add the >> body of the message quoted with '> '. >> >> git send-email --in-reply-to= --fetch => fetch and do like >> using the default configuration for fetch. > > We designed a similar UI, except for the --fetch option: > > We wanted to try to fetch the email from a distant server (e.g. gmane) > if that server address was set in the config file, and populate the > To:/Cc: fields. > > If the file cannot be downloaded, or server address not set, just fill > the Reply-to header. I'm not sure this is right. I'd typically configure gmane in my user-wide config file, so I'd have it configured all the time, but I may not always want to fetch from it (e.g. replying to a message which is not on a mailing-list, or if gmane is down, or ...). Fetching by default would clearly work in most cases, but for the few remaning cases it may be painful for the user if the only way to disable fetching is to remove the configuration from the config file. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
On 05/25/2016 08:31 PM, Matthieu Moy wrote: So, a possible UI would be: git send-email --in-reply-to= => just set In-Reply-To: field. git send-email --in-reply-to= => set In-Reply-To, To and Cc. git send-email --in-reply-to= --cite => in addition, add the body of the message quoted with '> '. git send-email --in-reply-to= --fetch => fetch and do like using the default configuration for fetch. We designed a similar UI, except for the --fetch option: We wanted to try to fetch the email from a distant server (e.g. gmane) if that server address was set in the config file, and populate the To:/Cc: fields. If the file cannot be downloaded, or server address not set, just fill the Reply-to header. Either way, display what was done with the message-id given (unless --quiet is set, of course). This leaves room for: git send-email --in-reply-to= --fetch=gmane => fetch from gmane (details on how to fetch would be in the config file) This UI wouldn't allow using a file to get only the message-id. But I'm not sure this is an interesting use-case. IMHO when you reply to a thread with a patch, it seems counter-productive to reply without notifying (putting in To:/Cc:) the original author and people involved in the thread. -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Junio C Hamano writes: > Matthieu Moy writes: > >> This should work, but sounds like too much of overloading of >> --in-reply-to IMHO: if given a message id, it would only add a reference >> to this message-id, but if given a file, it would also modify the To: >> and Cc: list. >> >> Not a strong objection, though. > > Well, with your "that is the plan indeed", the option would behave > the same whether given a message ID or a filename, no? The "fetch message from ID" feature should not be unconditional IMHO. So it would probably be stg like: git send-email --in-reply-to= --fetch What's a bit counter-intuitive is that --fetch would not only trigger fetching the complete message, but also populate To/Cc. But thinking about it, it's not _that_ counter-intuitive, as fetching the message should be done for a reason, so the user can guess that the message is going to be used for something. So, a possible UI would be: git send-email --in-reply-to= => just set In-Reply-To: field. git send-email --in-reply-to= => set In-Reply-To, To and Cc. git send-email --in-reply-to= --cite => in addition, add the body of the message quoted with '> '. git send-email --in-reply-to= --fetch => fetch and do like using the default configuration for fetch. This leaves room for: git send-email --in-reply-to= --fetch=gmane => fetch from gmane (details on how to fetch would be in the config file) This UI wouldn't allow using a file to get only the message-id. But I'm not sure this is an interesting use-case. So, I guess you convinced me. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Matthieu Moy writes: > This should work, but sounds like too much of overloading of > --in-reply-to IMHO: if given a message id, it would only add a reference > to this message-id, but if given a file, it would also modify the To: > and Cc: list. > > Not a strong objection, though. Well, with your "that is the plan indeed", the option would behave the same whether given a message ID or a filename, no? But I do agree that those who have accustomed to the behaviour of --in-reply-to that does not mess with To/Cc:, such a behaviour change is not desirable. If we are adding a new --reply-to-email=, it should behave as a superset of --in-reply-to (i.e. it should set In-Reply-to: using the message ID of the e-mail we are replying to), though. >> In the future, you might even teach send-email, perhaps via a user >> configurable hook, a way to get to the message header and text given a >> message-id, and when it happens, the same logic can be used when >> --in-reply-to is given a message-id (i.e. you go from the id to the >> message and find the addresses you would To/Cc: your message). > > That is the plan indeed. Fetching from gmane for example should be > rather easy in perl, and would be really convenient! -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Junio C Hamano writes: > I wonder if we can safely repurpose existing --in-reply-to option? In theory, obviously no as there can be a file with this name _and_ it can be a valid message-id. In practice, it is clearly unlikely. The only use-case I can think of where both would be valid is if the user happens to have saved the message using the message-id as filename. But then, the ambiguity would not harm, as the message-id contained in the file would be the same as the filename. > That is, if the value of --in-reply-to can be reliably determined as > a filename that has the message (as opposed to a message-id), we > read the "Message-Id:" from that file to figuire out what message-id > to use, and figure out To/Cc: to use for the purpose of your (1) at > the same time. This should work, but sounds like too much of overloading of --in-reply-to IMHO: if given a message id, it would only add a reference to this message-id, but if given a file, it would also modify the To: and Cc: list. Not a strong objection, though. > In the future, you might even teach send-email, perhaps via a user > configurable hook, a way to get to the message header and text given a > message-id, and when it happens, the same logic can be used when > --in-reply-to is given a message-id (i.e. you go from the id to the > message and find the addresses you would To/Cc: your message). That is the plan indeed. Fetching from gmane for example should be rather easy in perl, and would be really convenient! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Matthieu Moy writes: > Actually, I'm not sure what the ideal behavior should be. Perhaps it's > better to distinguish 1) and 2) above, and have two options > --reply-to-email= doing 1), and --quote doing 2), implying > --compose and requiring --reply-to-email. I tend to agree that sounds like a better way to structure these features. I wonder if we can safely repurpose existing --in-reply-to option? That is, if the value of --in-reply-to can be reliably determined as a filename that has the message (as opposed to a message-id), we read the "Message-Id:" from that file to figuire out what message-id to use, and figure out To/Cc: to use for the purpose of your (1) at the same time. In the future, you might even teach send-email, perhaps via a user configurable hook, a way to get to the message header and text given a message-id, and when it happens, the same logic can be used when --in-reply-to is given a message-id (i.e. you go from the id to the message and find the addresses you would To/Cc: your message). > In any case, quoting the message without replying to it does not make > sense (especially if you add instructions to trim it: the user would not > even see it). So it its current form, I'd say --quote-email should imply > --annotate. -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Samuel GROOT writes: > On 05/23/2016 10:00 PM, Matthieu Moy wrote: > >> Your --quote-mail does two things: >> >> 1) Populate the To and Cc field >> >> 2) Include the original message body with quotation prefix. >> [...] >> * If --compose is not given, don't send a cover-letter but cite the body >> as comment in the first patch. > > Then should the option imply `--annotate`, to let the user edit the > patch containing the quoted email? Actually, I'm not sure what the ideal behavior should be. Perhaps it's better to distinguish 1) and 2) above, and have two options --reply-to-email= doing 1), and --quote doing 2), implying --compose and requiring --reply-to-email. That would be more flexible, but that would require two new options, and I also like to keep things simple. In any case, quoting the message without replying to it does not make sense (especially if you add instructions to trim it: the user would not even see it). So it its current form, I'd say --quote-email should imply --annotate. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
On 05/25/16 00:30, Aaron Schrab wrote: > At 14:49 +0200 24 May 2016, Matthieu Moy > wrote: >> Samuel GROOT writes: >> >>> What kind of help text would you want to see? >>> >>> Maybe something like this: >>> >>> GIT: Quoted message body below. >>> GIT: Feel free to trim down the quoted text >>> GIT: to only relevant portions. >>> >>> As "GIT:" portions are ignored when parsed by `git send-email`. >> >> That's an option, but in the context of email, I think these >> instructions are not necessary. > > In an ideal world that would be true. But in the real world I think > evidence of many messages to this mailing list containing full quotes > suggests it might be helpful. I'd actually argue that the message be > more forceful, making it a suggestion/request to trim rather than simply > telling the user that it's allowed. Furthermore, it is a good way to avoid very long messages due to unnecessary parts quoted. Therefore, we thought about a request like "Please, trim down irrelevant sections in the quoted message to keep your email concise" -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
On 05/23/2016 10:00 PM, Matthieu Moy wrote: I don't think this is right: I often reply to an email with a single patch, for which it would clearly be overkill to have a cover-letter. Yes indeed, we are working on inserting the quoted message body in the patch's "below-triple-dash" section. Your --quote-mail does two things: 1) Populate the To and Cc field 2) Include the original message body with quotation prefix. When not using --compose, 1) clearly makes sense already, and there's no reason to prevent this use-case. When sending a single patch, 2) also makes sense as "below-tripple-dash comment", like This is the commit message for feature A. --- John Smith wrote: > You should implement feature A. Indeed, here's a patch. modified-file.c | 99 ++- When sending multiple patches without --compose, 2) may not make sense, but I think a sane behavior would be: * If --compose is given, cite the message there. * If --compose is not given, don't send a cover-letter but cite the body as comment in the first patch. As a first step, the second point can be changed to "if --compose is not given, don't cite the message, just populate the To: and Cc: fields". It seems a good behavior to me too. * If --compose is not given, don't send a cover-letter but cite the body as comment in the first patch. Then should the option imply `--annotate`, to let the user edit the patch containing the quoted email? + push(@header, $_); I think the code would be clearer if @header was a list of pairs (header-name, header-content). Then you'd need much less regex magic when going through it. The next series of patches may include (if the code is clean enough by then) a cleaner subroutine to parse the email, probably returning something like: return ( "from" => $from, "subject" => $subject, "date" => $date, "message_id" => $message_id, "to" => [@to], "cc" => [@cc], "xh" => [@xh], "config" => {%config} ); + elsif (/^From:\s+(.*)$/i) { + push @initial_to, $1; + } + elsif (/^To:\s+(.*)$/i) { + foreach my $addr (parse_address_line($1)) { + if (!($addr eq $initial_sender)) { + push @initial_to, $addr; + } + } This adds the content of the To: field in the original email to the Cc: field in the new message, right? If so, this is a weird behavior: when following up to an email, one usually addresses to the person s/he's replying, keeping the others Cc-ed, hence the original From: becomes the To header, and the original To: and Cc: become Cc:. We made the option behave like Thunderbird does, but indeed RFC 2822 [1] sees it the same you do, it will be fixed in next iteration. @@ -676,6 +771,8 @@ From: $tpl_sender Subject: $tpl_subject In-Reply-To: $tpl_reply_to +$tpl_quote + EOT Doesn't this add two extra useless blank lines if $tpl_quote is empty? Yes it does, it will be fixed in the next series of patches. Thank you for your time! [1] https://www.ietf.org/rfc/rfc2822.txt -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
At 14:49 +0200 24 May 2016, Matthieu Moy wrote: Samuel GROOT writes: What kind of help text would you want to see? Maybe something like this: GIT: Quoted message body below. GIT: Feel free to trim down the quoted text GIT: to only relevant portions. As "GIT:" portions are ignored when parsed by `git send-email`. That's an option, but in the context of email, I think these instructions are not necessary. In an ideal world that would be true. But in the real world I think evidence of many messages to this mailing list containing full quotes suggests it might be helpful. I'd actually argue that the message be more forceful, making it a suggestion/request to trim rather than simply telling the user that it's allowed. -- 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: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
Samuel GROOT wrote: > On 05/23/2016 09:55 PM, Eric Wong wrote: > >Cool! There should probably be some help text to encourage > >trimming down the quoted text to only relevant portions. > > What kind of help text would you want to see? > > Maybe something like this: > > GIT: Quoted message body below. > GIT: Feel free to trim down the quoted text > GIT: to only relevant portions. > > As "GIT:" portions are ignored when parsed by `git send-email`. Yes, given we have instructions for diffstat and table of contents; I think it'd be useful to discourage quoting irrelevant parts of the message (especially signatures and like). -- 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