[PATCH] Added new send extension

[John Goerzen]

On 2007-03-22, Matt Mackall <mpm at selenic.com> wrote:
> Sure. But the more I think about it, I think we probably want this to
> be part of patchbomb so that we only have one email command.

I think that makes things overly complex.  Let me illustrate.

Here's what the new hg email would look like:

 -a --attach    send patches as inline attachments
                always on with --bundle
    --bcc       email addresses of blind copy recipients
 -c --cc        email addresses of copy recipients
 -d --diffstat  add diffstat output to messages
                invalid with --bundle
 -g --git       use git extended diff format
                invalid with --bundle
 -f --from      email address of sender
    --plain     omit hg patch header
                invalid with --bundle
 -n --test      print messages that would be sent
 -m --mbox      write messages to mbox file instead of sending them
 -s --subject   subject of first message (intro, single patch, or bundle)
 -t --to        email addresses of recipients
    --outgoing  select changesets that aren't in the destination
                requires a destination to be given
    --bundle    attach a binary Mercurial bundle, using one message
    --force     run even when remote repository is unrelated
                requires --outgoing or --bundle
    --base      a base changeset to specify instead of a destination
                requires --bundle, incompatible with --outgoing
 -e --ssh       specify ssh command to use
                invalid without --outging or --bundle
    --remotecmd specify hg command to run on the remote side
                requires --outgoing or --bundle

Now our simple "hg send" has turned into "hg email --outgoing default
--bundle" -- at best.  That's a lot of typing, and the fact that you
have to use "default" is non-obvious to me.

> So for patch style, we can use -a, -d, -g, and --plain. For bundles,
> we can use -b, --base, and -r. The other options apply to both modes.
> For projects which always want bundles, people can add -b to their
> .hg/hgrc.

I think that this makes hg email exceptionally complex.  I would have
trouble reading that list there and figuring out what it does and how to
use it.  Plus the code would be complex.  In some modes, it generates a
series of emails with a PATCH x of y header.  In others, that would be
left off entirely.  In some modes, there's always a binary attachment.
In others, maybe inline text or a text attachment.

I think the right answer for code consolidation is to move more of
patchbomb.py into mercurial/mail.py and make it lightweight to create
new extensions that email things and take the same general paramaters
that patchbomb takes.  This would reduce code duplication between
patchbomb and send, and I've already volunteered to do it.

Even option parsing the above is complex, because there are so many
options that are valid in one mode or another, or invalidated by one
mode or another.

I think that combining the two violates KISS, both for users and for the
code, and that the code size will be smallest if we move common bits to
mail.py rather than try to make patchbomb.py do both.

FWIW, here's the help from hg send:

    --bcc        email addresses of blind copy recipients
 -c --cc         email addresses of copy recipients
 -f --from       email address of sender
 -s --subject    subject of message
 -t --to         email addresses of recipients
    --force      run even when remote repository is unrelated
 -r --rev        a changeset you would like to bundle
    --base       a base changeset to specify instead of a destination
 -e --ssh        specify ssh command to use
    --remotecmd  specify hg command to run on the remote side

This is exactly the options for hg bundle (without the -f shortcut for
--force), with email settings added in.  I think it looks a lot simpler
than a hybrid email.  That takes 10 lines to explain.  Current hg email
takes 11 (with --outgoing, 12).  The combined hg email above is 26.

-- John