The current mail notification system for Hg changes is not good. Specifically:

1. Merge changesets are skipped, but this means bad merges, or even correct but nontrivial merges, are not reported to
anyone.

2. Diffs are truncated at just 300 lines, which is inadequate.

3. The same message can be sent to many lists. If you subscribe to several, you get duplicates.

4. A change to 500 files in web.core and 1 file in nbbuild will result in a message to cvs@web and cvs@nbbuild with the
complete (but truncated) patch. Probably the cvs@nbbuild subscriber is interested just in the changes made in nbbuild.

5. There is no clear way how mail notification for clones should be configured.

6. If a branch is merged, dozens of messages may be sent, but it is hard to review the changes because you see the
history of every mistake, rather than a summary of the final result.

7. Diffs do not use --git, so renames do not appear correctly.

My proposal:

Stop keeping .hgmail in the same repo. Have a separate repo (or just nb-hooks?) containing e.g.

hgmail/main
hgmail/core-main
hgmail/some-random-branch

etc., where each file configures mail notification for that repo independently.

Change the email notification hook to behave as follows:

1. Collect a list of all changesets being pushed in this block. Just record their IDs, authors, and messages for later.

2. Perform a diff from the original tip to the new tip and examine the list of all files mentioned in the diff. Or
otherwise create a list of all files changed between original and new tip.

3. Collect a list of all email aliases corresponding to those files in hgmail/$repo.

4. For each alias, say "cvs@web=web.*/*":

4a. Run diff --git -r oldtip -r tip web.*/*

4b. Truncate diff to, say, 5000 lines.

4c. Send message to the alias with the diff preceded by a list of all the changesets, hyperlinked with message and
author info. (Ideally would restrict list to changesets which affect the files in e.g. web.*/*, though this might be
tricky in the case of merges, and must be checked carefully to make sure it works for renames and deletes too.)

Now everyone subscribed to (say) cvs@nbbuild will see exactly what changed in nbbuild/* with each push, regardless of
how that was distributed across different changesets.