Re: Reply for Auto parts

[Abiba]

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

[Shill Sheila Johnson]

I am still waiting for your reply to my letter to you, Get back to me so that I can give you more details.

[Sindiy Abiu]

I want you to Distribute my funds to less priviledge if interested reply now

[Shill Sheila Johnson]

Reply-to: hm-treasury_off...@my.com

[JC duet]

You are lucky to have £1,800,000.00GBP as your compensation grant.


JC

Reply

[Buka Saraki]

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

[Mr. X]

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

[Billy Wilfred]

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

[Richard & Angela Maxwell]

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

[Stefan Agner]

On 18.04.2018 02:54, Eric Wong wrote:
> Stefan Agner <ste...@agner.ch> 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

[Eric Wong]

Stefan Agner <ste...@agner.ch> 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

[Stefan Agner]

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 <ste...@agner.ch>
---
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

[Stefan Agner]

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

[Benjamin Joseph]

Good Day
My name is Benjamin Joseph, an accountant with C 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

[Doris Markkoh]

-- 

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

[Kuan Wai Chang]

Would you like to be part of our supply? 

Please respond back to my private email 

on: kuanwaich...@gmail.com

Reply

[Tamale David]

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

[Junio C Hamano]

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

[Christian Ludwig]

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 <chrissic...@gmail.com>
---
 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 <<EOT1, Git::prefix_lines("GIT: ", __ <<EOT2), <<EOT3;
 From $tpl_sender # This line is ignored.
@@ -689,6 +692,7 @@ for the patch you are writing.
 Clear the body content if you don't wish to send a summary.
 EOT2
 From: $tpl_sender
+Reply-To: $tpl_reply_to
 Subject: $tpl_subject
 In-Reply-To: $tpl_in_reply_to
 
@@ -731,6 +735,9 @@ EOT3
if ($parsed_email{'In-Reply-To'}) {
    $initial_in_reply_to = delete($parsed_email{'In-Reply-To'});
}
+   if ($parsed_email{'Reply-To'}) {
+   $reply_to = delete($parsed_email{'Reply-To'});
+   }
if ($parsed_email{'Subject'}) {
$initial_subject = delete($parsed_email{'Subject'});
print $c2 "Subject: " .
@@ -924,6 +931,12 @@ if (defined $initial_in_reply_to) {
$initial_in_

git-send-email: Support for Reply-To

[Christian Ludwig]

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

[Robert Worton]

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

[Martin Ågren]

On 17 January 2018 at 19:08, Christian Ludwig
<chrissic...@googlemail.com> 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 <chrissic...@gmail.com>

"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

[Ævar Arnfjörð Bjarmason]

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

[Junio C Hamano]

Christian Ludwig <chrissic...@googlemail.com> 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 <chrissic...@gmail.com>
> ---
>  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

[Christian Ludwig]

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 <chrissic...@gmail.com>
---
 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 <<EOT1, Git::prefix_lines("GIT: ", __ <<EOT2), <<EOT3;
 From $tpl_sender # This line is ignored.
@@ -688,6 +691,7 @@ for the patch you are writing.
 Clear the body content if you don't wish to send a summary.
 EOT2
 From: $tpl_sender
+Reply-To: $tpl_reply_to
 Subject: $tpl_subject
 In-Reply-To: $tpl_in_reply_to
 
@@ -738,6 +742,9 @@ EOT3
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_in_reply_to = $1;
next;
+   } elsif (/^Reply-To:\s*(.+)\s*$/i) {
+   $reply_to = $1;
+   next;
} elsif (/^From:\s*(.+)\s*$/i) {
$sender = $1;
next;
@@ -884,6 +891,12 @@ if (d

Re: [PATCH] send-email: Support separate Reply-To address

[SZEDER Gábor]

> 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 <chrissic...@gmail.com>
> ---
>  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

[Christian Ludwig]

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 <chrissic...@gmail.com>
---
 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 <<EOT1, Git::prefix_lines("GIT: ", __ <<EOT2), <<EOT3;
 From $tpl_sender # This line is ignored.
@@ -688,6 +691,7 @@ for the patch you are writing.
 Clear the body content if you don't wish to send a summary.
 EOT2
 From: $tpl_sender
+Reply-To: $tpl_reply_address
 Subject: $tpl_subject
 In-Reply-To: $tpl_reply_to
 
@@ -738,6 +742,9 @@ EOT3
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_reply_to = $1;
next;
+   } elsif (/^Reply-To:\s*(.+)\s*$/i) {
+   $reply_address = $1;
+   next;
} elsif (/^From:\s*(.+)\s*$/i) {
$sender = $1;
next;
@@ -884,6 +891,12 @@ if (defined $initial_reply_to) {
$initial_reply_to = "<$initial_reply_to>" if $initial_reply_to ne '';
 }
 
+if (defined $reply_address) {
+   $reply_address =~ s/^\s+|\s+$//g;
+   ($reply_address) = expand_aliases($reply_address);
+   $reply_address = sanitize_address($reply_address);
+}
+
 if (!defined $smtp_server) {
my @sendmail_paths = qw( /usr/sbin/sendmail /usr/lib/sendmail );
push @sendmail_paths, map {"$_/sendmail"} split /:/, $ENV{PATH};
@@ -1315,6 +1328,9 @@ Message-Id: $message_id
$header .= "In-Reply-To: $reply_to\n";
$header .= "References: $references\n";
}
+   if ($reply_address) {
+   $header .= "Reply-To: $reply_address\n";
+   }
if (@xh) {
$header .= join("\n", @xh

Please reply immediately,

[Mrs. Sarah Faith.]

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,

[Mr,Nodian Omera]

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.

[Hussein Saleh]

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

[Wong]

I have something very confidential and private to discuss with you 

Re: [PATCH] patch reply

[Marius Paliga]

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

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

[PATCH] patch reply

[Thais Diniz]

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

[Mr.Patrick Joseph]

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

[Info]

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:

[Mrs Mavis Wanczyk]

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.

[Alaine Kamba]

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

[mrsjulianatimothy]

I Have A Donation For You

URGENT REPLY FOR MORE DETAILS.

[casimire kere]

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.

[casimire kere]

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.

[Casmire Kere]

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

[Amuji Gab,]

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

[Makl Na]

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

[Mr.Adams Salem]

I have been trying to reach you

this is urgent reply.

[Mr. zaki ibrahim.]

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

[Fani Investment]

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

[IBRAHIM KABORE]

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

[Mrs Gloria]

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

[Junio C Hamano]

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

[Johannes Sixt]

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

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

Thanks.

[PATCH v4 1/3] usability: don't ask questions if no reply is required

[Jean-Noel Avila]

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 <jn.av...@free.fr>
---
 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

[Jean-Noel Avila]

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 <jn.av...@free.fr>
---
 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

[Ævar Arnfjörð Bjarmason]

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

[Konstantin Khomoutov]

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

[Kerry, Richard]

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 <jn.av...@free.fr>
> 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 <jn.av...@free.fr> 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",
>   argv[0], opts.new_branch);

"'%s' can not be resolved as commit, but it should."
It should what ?  Be resolved, or commit?  Or something els

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Junio C Hamano]

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

[Ævar Arnfjörð Bjarmason]

On Tue, May 9, 2017 at 10:18 AM, Jean-Noël AVILA <jn.av...@free.fr> 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 <richard.ke...@atos.net> 
>> 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

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Jean-Noël AVILA]

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 <richard.ke...@atos.net> 
> 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 <jn.av...@free.fr>
> > 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 "spel

RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Kerry, Richard]

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 <richard.ke...@atos.net> 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 <jn.av...@free.fr>
> 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 

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Jean-Noël AVILA]

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

[Ævar Arnfjörð Bjarmason]

On Thu, May 4, 2017 at 10:52 AM, Kerry, Richard <richard.ke...@atos.net> 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 <jn.av...@free.fr>
> 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 <jn.av...@free.fr>
> ---
>  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/bui

RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required

[Kerry, Richard]

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 <jn.av...@free.fr>
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 <jn.av...@free.fr>
---
 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 entities are registered in 
England and Wales: Atos IT Service

[PATCH v2 1/3] usability: don't ask questions if no reply is required

[Jean-Noel Avila]

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 <jn.av...@free.fr>
---
 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

[Jean-Noël AVILA]

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 <jn.av...@free.fr>
> > ---
> > 
> >  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

Re: [PATCH 1/4] usability: don't ask questions if no reply is required

[Stefan Beller]

+cc rashmipa...@gmail.com

On Wed, May 3, 2017 at 9:47 AM, Jonathan Nieder <jrnie...@gmail.com> 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 <jn.av...@free.fr>
>> ---
>>  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

[Jonathan Nieder]

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 <jn.av...@free.fr>
> ---
>  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

[Jean-Noel Avila]

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 <jn.av...@free.fr>
---
 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)

[Yohana Rocio Morales Chacon]

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.

[Ahmed Zongo]

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

[Junio C Hamano]

Eric Wong <e...@80x24.org> writes:

> Junio C Hamano <gits...@pobox.com> 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

[Eric Wong]

Junio C Hamano <gits...@pobox.com> wrote:
> Eric Wong <e...@80x24.org> 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

[Junio C Hamano]

Eric Wong <e...@80x24.org> 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

[Eric Wong]

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

[Bank of England]

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

[Rebecca Taylor]

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

[CHAN CHAK]

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

[Samuel GROOT]

On 06/09/2016 11:45 AM, Matthieu Moy wrote:

Samuel GROOT <samuel.gr...@grenoble-inp.org> 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=<Message-Id|email_file>::
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

[Samuel GROOT]

On 06/08/2016 08:23 PM, Junio C Hamano wrote:

Samuel GROOT <samuel.gr...@grenoble-inp.org> 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

[Matthieu Moy]

Samuel GROOT <samuel.gr...@grenoble-inp.org> 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=<Message-Id|email_file>::
>   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

[Junio C Hamano]

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

[Samuel GROOT]

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 <tom.russe...@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr>
---
 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=<Message-Id|email_file>::
    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_refer

[PATCH v3 5/6] send-email: --in-reply-to= populates the fields

[Tom Russello]

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 <tom.russe...@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.gr...@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu@grenoble-inp.fr>
---
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=<Message-Id|email_file>::
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 {
+   

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

[Matthieu Moy]

Samuel GROOT <samuel.gr...@grenoble-inp.org> 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

[Samuel GROOT]

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

[Matthieu Moy]

Junio C Hamano <gits...@pobox.com> writes:

> Matthieu Moy <matthieu@grenoble-inp.fr> 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

[Junio C Hamano]

Matthieu Moy <matthieu@grenoble-inp.fr> 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=<file|id>, 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

[Matthieu Moy]

Junio C Hamano <gits...@pobox.com> 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

[Junio C Hamano]

Matthieu Moy <matthieu@grenoble-inp.fr> 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

[Matthieu Moy]

Samuel GROOT <samuel.gr...@grenoble-inp.org> 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

[Tom Russello]

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

[Samuel GROOT]

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

[Aaron Schrab]

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

[Eric Wong]

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

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

[Matthieu Moy]

Samuel GROOT  writes:

> On 05/23/2016 09:55 PM, Eric Wong wrote:
>> Tom Russello  wrote:
>>> This new option takes an email message file, parses it, fills the "To",
>>> "Subject" and "Cc" fields appropriately and quote the message.
>>> This option involves the `--compose` mode to edit the cover letter quoting 
>>> the
>>> given email.
>>
>> 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`.

That's an option, but in the context of email, I think these
instructions are not necessary.

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

[Samuel GROOT]

On 05/23/2016 09:55 PM, Eric Wong wrote:

Tom Russello  wrote:

This new option takes an email message file, parses it, fills the "To",
"Subject" and "Cc" fields appropriately and quote the message.
This option involves the `--compose` mode to edit the cover letter quoting the
given email.


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

On 05/23/2016 10:07 PM, Matthieu Moy wrote:

Eric Wong <e...@80x24.org> writes:


Tom Russello <tom.russe...@grenoble-inp.org> wrote:


+   #Message body
+   while (<$fh>) {
+   #for files containing crlf line endings
+   $_=~ s/\r//g;
+   my $space="";
+   if (/^[^>]/) {
+   $space = " ";
+   }
+   $message_quoted .=  ">".$space.$_;


Is this really necessary to switch between "> " and ">" prefix?
AFAIK, MUAs prefix unconditionally with "> ".


I had the same question, but at least my mailer (Gnus) has the same
special-case it seems.



Thunderbird behaves the same way, so we decided to mimic that behavior.

It is specified neither in RFC 2822 [1] nor in RFC 5322 [2].

When we write an email, we write it with a maximum width of 72 columns. 
If we insert "> " with each reply, the 80-columns limit will be reached 
with only 4 replies.


So IMHO we should trim the extra space to allow up to 7 replies before 
reaching the 80-columns limit.



[1] https://www.ietf.org/rfc/rfc2822.txt
[2] https://www.ietf.org/rfc/rfc5322.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

[Matthieu Moy]

Eric Wong  writes:

> Tom Russello  wrote:
>
>> +#Message body
>> +while (<$fh>) {
>> +#for files containing crlf line endings
>> +$_=~ s/\r//g;
>> +my $space="";
>> +if (/^[^>]/) {
>> +$space = " ";
>> +}
>> +$message_quoted .=  ">".$space.$_;
>
> Is this really necessary to switch between "> " and ">" prefix?
> AFAIK, MUAs prefix unconditionally with "> ".

I had the same question, but at least my mailer (Gnus) has the same
special-case it seems.

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

Tom Russello <tom.russe...@grenoble-inp.org> writes:

> This option involves the `--compose` mode to edit the cover letter quoting the

s/involves/implies/

?

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.

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

> ---
>
> diff --git a/git-send-email.perl b/git-send-email.perl

No diffstat?

> @@ -638,6 +640,98 @@ if (@files) {
>   print STDERR "\nNo patch files specified!\n\n";
>   usage();
>  }
> +my $message_quoted;
> +if ($quote_mail) {

Style: The code you're adding doesn't look related to the code right
before => separate them with a blank line.

> + while(<$fh>) {

Style: space before (.

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

> + #for files containing crlf line endings

Sytle: space after #.

> + foreach(@header) {

Space before (.

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

> + } elsif (/^Cc:\s+(.*)$/i) {

Style: IIRC, there's no consensus on whether "elsif" should be on the
same line as the closing }, but please follow the same convention inside
a single if/elsif/ chain.

> + #Message body

Style: space after # (more below). And while you're there, the comment
could be "Quote the message body" or so, to give a hint to the user
about what's going on.

> + while (<$fh>) {
> + #for files containing crlf line endings
> + $_=~ s/\r//g;
> + my $space="";

Style: spaces around =.

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

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