Less frequent/verbose notifications for hg push

Question

My project uses hgext.notify. Currently incoming.notify = separate messages on every changeset. Considering changegroup notify, but even that contains info about every changeset, just all in one big email.

Here's the problem:

My work style is "check in early and often". I make many small checkins, usually on branches. Task branches. Eventually integrated.

My teammates do not like seeing messages for all of my checkins on my task branches.

We are considering using a history editing extension like collapse or histedit to reduce the verbosity - but I dislike losing history. I just want not to bother them with every individual changeset.

Q: is there a way, some configuration for an existing hook, or some alternate hg extension, that can be set up to do notifies as folllws;

1. a single message per changegroup (that's okay)

2. a single user provided message per changegroup - not just concatenation of all the branch changeset messages

3. filter out only the changest messages for, say, the trunk (the default branch in hg parlance). I.e. leave the branch changeset messages in, but don't send email.

   (Note: my pushes typically involve several changesets on a branch, and then a merge onto default. So it is not enough to just filter the entire changegroup in or out according to what branches are affected.)

4. diffstats not between the tip and every changest on the branch, but just between "important" changesets on the trunk (default branch) - which may be evety changest on the trunk.

Answer 1

I'm afraid no such extension exists. The notify extension is just a basic way to send off emails with a little room for customization.

It sounds like you have a particular idea about what you want. I suggest you see if you can formulate it as a revision set and then simply use hg log in a changegroup hook. Pipe the output to mail and you've got yourself a very simple notify extension that you can customize to your hearts content!

What I'm saying is that the notify extension is not that complex and in many cases it can be replaced by a suitable invocation of hg log. You can even use a custom template for hg log if you want to change the output more than what hg log -v or hg log --patch does.

The tricky part (and the part that's not entirely clear from your question) is to filter out exactly the right changesets. You mention "important" changesets in point 4 above, but I'm not entirely sure what makes a changeset "important". If it is important when it's a merge from a feature branch into default, then something like this might be a start:

hg log -r "$HG_NODE:tip and children(not branch(default)) and branch(default)"

By taking the child changesets of the non-default changesets and intersecting with changesets on the default, we get exactly the merge points where feature branches were integrated.

I'm sorry the answer is so generic, but I think you're best off with writing a small custom shell script for what you want.