Contents
command to send changesets as (a series of) patch emails
The series is started off with a "[PATCH 0 of N]" introduction, which describes the series as a whole.
Each patch email has a Subject line of "[PATCH M of N] ...", using the first line of the changeset description as the subject text. The message contains two or three body parts:
Each message refers to the first in the series using the In-Reply-To and References headers, so they will show up as a sequence in threaded mail and news readers, and in mail archives.
To configure other defaults, add a section like this to your configuration file:
[email] from = My Name <my@email> to = recipient1, recipient2, ... cc = cc1, cc2, ... bcc = bcc1, bcc2, ... reply-to = address1, address2, ...
Use [patchbomb] as configuration section name if you need to override global [email] address settings.
Then you can use the hg email command to mail a series of changesets as a patchbomb.
You can also either configure the method option in the email section to be a sendmail compatible mailer or fill out the [smtp] section so that the patchbomb extension can automatically send patchbombs directly from the commandline. See the [email] and [smtp] sections in hgrc(5) for details.
By default, hg email will prompt for a To or CC header if you do not supply one via configuration or the command line. You can override this to never prompt by configuring an empty value:
[email] cc =
You can control the default inclusion of an introduction message with the patchbomb.intro configuration option. The configuration is always overwritten by command line flags like --intro and --desc:
[patchbomb] intro=auto # include introduction message if more than 1 patch (default) intro=never # never include an introduction message intro=always # always include an introduction message
You can specify a template for flags to be added in subject prefixes. Flags specified by --flag option are exported as {flags} keyword:
[patchbomb]
flagtemplate = "{separate(' ',
ifeq(branch, 'default', '', branch|upper),
flags)}"
You can set patchbomb to always ask for confirmation by setting patchbomb.confirm to true.
send changesets by email:
hg email [OPTION]... [DEST]...
By default, diffs are sent in the format generated by hg export, one per message. The series starts with a "[PATCH 0 of N]" introduction, which describes the series as a whole.
Each patch email has a Subject line of "[PATCH M of N] ...", using the first line of the changeset description as the subject text. The message contains two or three parts. First, the changeset description.
With the -d/--diffstat option, if the diffstat program is installed, the result of running diffstat on the patch is inserted.
Finally, the patch itself, as generated by hg export.
With the -d/--diffstat or --confirm options, you will be presented with a final summary of all messages and asked for confirmation before the messages are sent.
By default the patch is included as text in the email body for easy reviewing. Using the -a/--attach option will instead create an attachment for the patch. With -i/--inline an inline attachment will be created. You can include a patch both as text in the email body and as a regular or an inline attachment by combining the -a/--attach or -i/--inline with the --body option.
With -B/--bookmark changesets reachable by the given bookmark are selected.
With -o/--outgoing, emails will be generated for patches not found in the destination repository (or only those which are ancestors of the specified revisions if any are provided)
With -b/--bundle, changesets are selected as for --outgoing, but a single email containing a binary Mercurial bundle as an attachment will be sent. Use the patchbomb.bundletype config option to control the bundle type as with hg bundle --type.
With -m/--mbox, instead of previewing each patchbomb message in a pager or sending the messages directly, it will create a UNIX mailbox file with the patch emails. This mailbox file can be previewed with any mail user agent which supports UNIX mbox files.
With -n/--test, all steps will run, but mail will not be sent. You will be prompted for an email recipient address, a subject and an introductory message describing the patches of your patchbomb. Then when all is done, patchbomb messages are displayed.
In case email sending fails, you will find a backup of your series introductory message in .hg/last-email.txt.
The default behavior of this command can be customized through configuration. (See hg help patchbomb for details)
Examples:
hg email -r 3000 # send patch 3000 only
hg email -r 3000 -r 3001 # send patches 3000 and 3001
hg email -r 3000:3005 # send patches 3000 through 3005
hg email 3000 # send patch 3000 (deprecated)
hg email -o # send all patches not in default
hg email -o DEST # send all patches not in DEST
hg email -o -r 3000 # send all ancestors of 3000 not in default
hg email -o -r 3000 DEST # send all ancestors of 3000 not in DEST
hg email -B feature # send all ancestors of feature bookmark
hg email -b # send bundle of all patches not in default
hg email -b DEST # send bundle of all patches not in DEST
hg email -b -r 3000 # bundle of all ancestors of 3000 not in default
hg email -b -r 3000 DEST # bundle of all ancestors of 3000 not in DEST
hg email -o -m mbox && # generate an mbox file...
mutt -R -f mbox # ... and view it with mutt
hg email -o -m mbox && # generate an mbox file ...
formail -s sendmail \ # ... and use formail to send from the mbox
-bm -t < mbox # ... using sendmail
Before using this command, you will need to enable email in your hgrc. See the [email] section in hgrc(5) for details.
Options:
| -g, --git | use git extended diff format |
| --plain | omit hg patch header |
| -o, --outgoing | send changes not found in the target repository |
| -b, --bundle | send changes not in target as a binary bundle |
| -B, --bookmark <BOOKMARK> | |
| send changes only reachable by given bookmark | |
| --bundlename <NAME> | |
| name of the bundle attachment file (default: bundle) | |
| -r, --rev <REV[+]> | |
| a revision to send | |
| --force | run even when remote repository is unrelated (with -b/--bundle) |
| --base <REV[+]> | |
| a base changeset to specify instead of a destination (with -b/--bundle) | |
| --intro | send an introduction email for a single patch |
| --body | send patches as inline message text (default) |
| -a, --attach | send patches as attachments |
| -i, --inline | send patches as inline attachments |
| --bcc <EMAIL[+]> | |
| email addresses of blind carbon copy recipients | |
| -c, --cc <EMAIL[+]> | |
| email addresses of copy recipients | |
| --confirm | ask for confirmation before sending |
| -d, --diffstat | add diffstat output to messages |
| --date <DATE> | use the given date as the sending date |
| --desc <FILE> | use the given file as the series description |
| -f, --from <EMAIL> | |
| email address of sender | |
| -n, --test | print messages that would be sent |
| -m, --mbox <FILE> | |
| write messages to mbox file instead of sending them | |
| --reply-to <EMAIL[+]> | |
| email addresses replies should be sent to | |
| -s, --subject <TEXT> | |
| subject of first message (intro or single patch) | |
| --in-reply-to <MSGID> | |
| message identifier to reply to | |
| --flag <FLAG[+]> | |
| flags to add in subject prefixes | |
| -t, --to <EMAIL[+]> | |
| email addresses of recipients | |
| -e, --ssh <CMD> | |
| specify ssh command to use | |
| --remotecmd <CMD> | |
| specify hg command to run on the remote side | |
| --insecure | do not verify server certificate (ignoring web.cacerts config) |
[+] marked option can be specified multiple times