Mercurial_ The Definitive Guide - Bryan O'Sullivan [110]
[extdiff]
cmd.vimdiff = vim
opts.vimdiff = -f '+next' '+execute "DirDiff" argv(0) argv(1)'
Cherry-Picking Changes with the transplant Extension
Need to have a long chat with Brendan about this.
Sending Changes via Email with the patchbomb Extension
Many projects have a culture of “change review,” in which people send their modifications to a mailing list for others to read and comment on before they commit the final version to a shared repository. Some projects have people who act as gatekeepers; they apply changes from other people to a repository to which those others don’t have access.
Mercurial makes it easy to send changes over email for review or application, via its patchbomb extension. The extension is so named because changes are formatted as patches, and it’s usual to send one changeset per email message. Sending a long series of changes by email is thus much like “bombing” the recipient’s inbox, hence “patchbomb.”
As usual, the basic configuration of the patchbomb extension takes just one or two lines in your /.hgrc.
[extensions]
patchbomb =
Once you’ve enabled the extension, you will have a new command available, named email.
The safest and best way to invoke the email command is to always run it first with the hg -n option. This will show you what the command would send, without actually sending anything. Once you’ve had a quick glance over the changes and verified that you are sending the right ones, you can rerun the same command, with the hg -n option removed.
The email command accepts the same kind of revision syntax as every other Mercurial command. For example, this command will send every revision between 7 and tip, inclusive.
hg email -n 7:tip
You can also specify a repository to compare with. If you provide a repository but no revisions, the email command will send all revisions in the local repository that are not present in the remote repository. If you additionally specify revisions or a branch name (the latter using the hg -b option), this will constrain the revisions sent.
It’s perfectly safe to run the email command without the names of the people you want to send to: if you do this, it will just prompt you for those values interactively. (If you’re using a Linux or Unix-like system, you should have enhanced readline-style editing capabilities when entering those headers, too, which is useful.)
When you are sending just one revision, the email command will by default use the first line of the changeset description as the subject of the single email message it sends.
If you send multiple revisions, the email command will usually send one message per changeset. It will preface the series with an introductory message, in which you should describe the purpose of the series of changes you’re sending.
Changing the Behavior of Patchbombs
Not every project has exactly the same conventions for sending changes in email; the patchbomb extension tries to accommodate a number of variations through command-line options.
You can write a subject for the introductory message on the command line using the hg -s option. This takes one argument, the text of the subject to use.
To change the email address from which the messages originate, use the hg -f option. This takes one argument, the email address to use.
The default behavior is to send unified diffs (see Understanding Patches for a description of the format), one per message. You can send a binary bundle instead with the hg -b option.
Unified diffs are normally prefaced with a metadata header. You can omit this and send unadorned diffs with the hg --plain option.
Diffs are normally sent “inline,” in the same body part as the description of a patch. This makes it easiest for the largest number of readers to quote and respond to parts of a diff, as some mail clients will only quote the first MIME body part in a message. If you’d prefer to send the description and the diff in separate body parts, use the hg -a option.
Instead of sending mail messages, you can write them to an