Differences between revisions 10 and 11
Revision 10 as of 2005-11-14 20:21:34
Size: 3567
Comment:
Revision 11 as of 2006-03-15 19:09:00
Size: 3649
Comment: add link to hgrc(5) for a complete list of hooks
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

See http://www.selenic.com/mercurial/hgrc.5.html for a complete list of hooks.

Commit Hooks

See http://www.selenic.com/mercurial/hgrc.5.html for a complete list of hooks.

You can use the hook feature to automatically send mail when a commit occurs. Add the following to .hg/hgrc:

[hooks]
commit = commithook

And put this in a file called commithook in your path:

SUBJECT=`hg log -r $NODE | grep "^summary:" | cut -b 14-`
hg log -vpr $NODE | mail -s "commit: $SUBJECT" commit-list@example.com

And something like this can be used for closing bugs in roundup:

ISSUE=`hg log -vr $NODE | grep -o "\<fix:[[:alnum:]]*" | head -n 1 | sed s/fix://`
[ -z $ISSUE ] && exit
SUBJECT=`hg log -r $NODE | grep "^summary:" | cut -b 14-`
hg log -vr $NODE | mail -s "[$ISSUE] [status=testing] commit: $SUBJECT" roundup@example.com

If you want multiple hooks, just add a suffix to the action, an empty command can be used to unset a site-wide hook:

[hooks]
# do not use the site-wide hook
commit =
commit.email = /my/email/hook
commit.autobuild = /my/build/hook

Commit mail for patch review

One common reason for commit emails is to review changes. When multiple committers push to a central, canonical repository and have changes mailed only when they push to the repository rather than whenever they do commits to their local clones, you can get the same data coming through multiple times, making it hard to review the changes. This happens because of merge commits; hg pull; hg update do work hg commit; hg pull; hg update -m; hg commit will give two commit messages; one for the work and one for the merge. Except when there are conflicts, the text of the commit message for the merge is all diff that is really part of the commit, but which doesn't represent an actual change to the central, canonical repository. So while the commit message is absolutely technically correct, the duplicate information that it provides tends to degrade the reviewing process, and in practice, we (rPath) saw it obscure accidental reversion from a bad merge.

It is possible to remove almost all of the duplicate information with a bit of scripting. The following script does the trick:

RECIP=""
MODULE=""

while [ $# -gt 0 ] ; do
    case $1 in
      --recip)
        shift
        RECIP="$RECIP $1"
        shift
        ;;
      --module)
        shift
        MODULE=$1
        shift
        ;;
    esac
done

hg update -C
SUBJECT=$(hg log -r $NODE | grep "^summary:" | cut -b 14-)

PARENT=$(hg log --debug -r $NODE | sed -n '/^parent:/{s/^.*: *.*://;p}' | head -1 )
FILES=$(hg log -v -r $NODE | sed -n '/^files:/{s/^.*: *//;p}')

if [ -z "$FILES" ]; then
    exit 0
fi

(hg log -vr $NODE | egrep -v '^(changeset|parent|date):' | sed 's/^description:$//' | cat -s ; hg diff -r $PARENT -r $NODE $FILES) | mail -s "$MODULE: $SUBJECT" $RECIP

This script filters out some of the other information that is really not needed for patch review: the changeset hash exists in the diff; the parents are available by using hg log on the changeset hash; the word "description" isn't really needed in this context, and so is filtered out as noise; the date is in the email header, etc. Some of the brevity introduced in this script was driven by one of its authors being in the habit of reading changemail on his Treo, but it seems to generally help focus the review process on the things that really changed. When we pointed this script at the node with the accidental inappropriate reversion, it went from being hidden in the noise to being painfully obvious.

Hook (last edited 2021-08-23 00:42:32 by PaulBissex)