Mercurial_ The Definitive Guide - Bryan O'Sullivan [76]
(filename, linenum))
added += 1
if added:
# save the commit message so we don't need to retype it
os.system('hg tip --template "{desc}" > .hg/commit.save')
print >> sys.stderr, 'commit message saved to .hg/commit.save'
sys.exit(1)
The above version is much more complex, but also more useful. It parses a unified diff to see if any lines add trailing whitespace, and prints the name of the file and the line number of each such occurrence. Even better, if the change adds trailing whitespace, this hook saves the commit comment and prints the name of the saved file before exiting and telling Mercurial to roll the transaction back, so you can use the -l filename option to hg commit to reuse the saved commit message once you’ve corrected the problem.
$ cat .hg/hgrc
[hooks]
pretxncommit.whitespace = .hg/check_whitespace.py
$ echo 'a ' >> a
$ hg commit -A -m 'add new line with trailing whitespace'
a, line 2: trailing whitespace added
commit message saved to .hg/commit.save
transaction abort!
rollback completed
abort: pretxncommit.whitespace hook exited with status 1
$ sed -i 's, *$,,' a
$ hg commit -A -m 'trimmed trailing whitespace'
a, line 2: trailing whitespace added
commit message saved to .hg/commit.save
transaction abort!
rollback completed
abort: pretxncommit.whitespace hook exited with status 1
As a final aside, note in the example above the use of sed’s in-place editing feature to get rid of trailing whitespace from a file. This is concise and useful enough that I will reproduce it here (using perl for good measure).
perl -pi -e 's,\s+$,,' filename
Bundled Hooks
Mercurial ships with several bundled hooks. You can find them in the hgext directory of a Mercurial source tree. If you are using a Mercurial binary package, the hooks will be located in the hgext directory of wherever your package installer put Mercurial.
acl—Access Control for Parts of a Repository
The acl extension lets you control which remote users are allowed to push changesets to a networked server. You can protect any portion of a repository (including the entire repo), so that a specific remote user can push changes that do not affect the protected portion.
This extension implements access control based on the identity of the user performing a push, not on who committed the changesets they’re pushing. It makes sense to use this hook only if you have a locked-down server environment that authenticates remote users, and you want to be sure that only specific users are allowed to push changes to that server.
Configuring the acl hook
In order to manage incoming changesets, the acl hook must be used as a pretxnchangegroup hook. This lets it see which files are modified by each incoming changeset, and roll back a group of changesets if they modify “forbidden” files. For example:
[hooks]
pretxnchangegroup.acl = python:hgext.acl.hook
The acl extension is configured using three sections.
The acl section has only one entry, sources, which lists the sources of incoming changesets that the hook should pay attention to. You don’t normally need to configure this section.
serve: Control incoming changesets that are arriving from a remote repository over http or ssh. This is the default value of sources, and usually the only setting you’ll need for this configuration item.
pull: Control incoming changesets that are arriving via a pull from a local repository.
push: Control incoming changesets that are arriving via a push from a local repository.
bundle: Control incoming changesets that are arriving from another repository via a bundle.
The acl.allow section controls the users that are allowed to add changesets to the repository. If this section is not present, all users that are not explicitly denied are allowed. If this section is present, all users that are not explicitly allowed are denied (so an empty section means that all users are denied).
The acl.deny section determines which users are denied from adding changesets to the repository. If this section is not present or is empty,