[PATCH 0 of 2] Resend: Parsing multiple addresses in patchbomb

Marti Raudsepp marti at juffo.org
Thu Nov 26 04:29:46 CST 2009


I'm re-submitting my patches to patchbomb that fix address parsing in hgrc and
add support for multiple addresses in a single --to/--cc/--bcc argument.

Patches rebased, modified slightly and re-tested with Python 2.6 and 2.4

Last time there was some opposition to this, so I listed my motivations for
persevering with this approach.

1. Drawbacks?
* Breaks the convention that "multiple arguments should be specified
  separately, not joined by a delimiter".
  Exceptions to this convention: --rev 1:2, arguably --include '{*.a,*.b}'

2. Why would the user expect new behavior?
* The --cc option could be read as "add a Cc: header with this value". In fact,
  this is what I thought patchbomb does until I discovered later that I had
  incomplete recipients on my email.
* 'hg email --test' further tricks the user into believing this, because it
  passes through email addresses unmangled.
* User can already use commas in configuration options or the interactive
  prompt. New behavior unifies them all in a consistent manner.
* 'git-send-email' allows both ways; other email clients also allow multiple
  email addresses separated by commas.
* There is no other legitimate reason why someone would use commas and include
  multiple recipients in an address argument.

3. Why is new behavior useful?
* Does the Right Thing -- if the user fell for reasons I listed above.
* Less typing.
* If you already have an existing email thread that you want to reply to, you
  can simply copy-paste the Cc: header from your mail client, without having to
  split addresses up by hand.


If you buy the reasons I listed in #2, the user should be at least given a
warning when (s)he attempts to use commas. But I don't believe in yelling at
the user if we can be helpful instead.

Implementing it this way is no more complicated. We need the 'parseaddrlist()'
function to properly parse configuration options anyway.

Regards,
Marti



More information about the Mercurial-devel mailing list