--confirm presents same prompt as --diffstat, but does not write
a diffstat to the messages' bodies.
A simple test simulating a negative response is included.
This changes the behaviour of --diffstat.
Before the user was asked for confirmation of each patch with its
description and diffstat, and a final summary.
Now there is only one prompt right before sending with a final
summary which does not include the patch descriptions, but the
message details and the diffstats:
Final summary:
From: sender
To: recipient(s)
Cc: (if present)
Bcc: (if present)
Reply-To: (if present)
Subject: [patch 0 of x [flags]] intro (if present)
a | 28 ++++++++++++++++++++++++++++
b | 15 +++++++++++++++
Subject: [patch 1 of x [flags]] subject
a | 28 ++++++++++++++++++++++++++++
[ ... ]
are you sure you want to send (yn)?
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
From RFC 5322:
an optional reply-to field MAY also be included, which contains the field
name "Reply-To" and a comma-separated list of one or more addresses.
[...]
When the "Reply-To:" field is present, it indicates the address(es) to which
the author of the message suggests that replies be sent. In the absence of
the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es)
specified in the "From:" field unless otherwise specified by the person
composing the reply.
Reply-To addresses may be specified either via command line with --reply-to
or via the 'email' or 'patchbomb' sections of the config file.
Previously, the name part of an repo#name url was interpreted as a
revision, similar to using the --rev option. Now it is instead looked
up as a branch first, and if that succeeds all the heads of the branch
will be processed instead of just its tip-most head. If the branch
lookup fails, it will be assumed to be an revision as before (e.g. for
tags).
mbox format should use time.asctime(). Unfortunately, this function writes
2-characters day of week on Windows while unix one writes a single character.
Normalize to Windows version since the other one can hardly be written with
strftime().
--flag foo uses:
[PATCH foo]
or
[PATCH M of N foo]
depending on the number of patches.
Multiple flags are supported: --flag foo --flag bar gives [PATCH foo bar]
Localized date in the From_ prevents MUAs like mutt from parsing mbox files
generated by patchbomb. Using a 24 characters date in asctime format instead.
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
RFC 5322 states:
"Semantically, the angle bracket characters are not part of the
msg-id; the msg-id is what is contained between the two angle bracket
characters."
Hence it should be correct to pass a message Id with no angle brackets
to --in-reply-to. Adding them if missing.
Instead of using custom code to split apart addresses, we now use
mail.parseaddrlist() which always does the Right Thing as it relies on Python's
email.Utils.getaddresses().
Previously, 'hg email --to=foo,bar' only respected foo and discarded bar. Also,
commas in names were not allowed in hgrc or the interactive prompt; specifying
'"Lastname, Firstname" <foo>' would confuse patchbomb.
The testcase uses '-m tmp.mbox' because -n (like in other tests) would disable
address mangling.
When specifying --in-reply-to for a message M, have
[M]
[0/2]
[1/2]
[2/2]
instead of
[M]
[0/2]
[1/2]
[2/2]
which is more consistent with the way messages are being threaded
when --in-reply-to is not used.
