comparison en/ch09-hook.xml @ 809:ef53d025f410

Mention qdelete and qimport -r.

808:557552d4699f

	you do not own (e.g. using <command role="hg-cmd">hg
	  pull</command> or <command role="hg-cmd">hg
	  incoming</command>), remember that it is the other
	repository's hooks you should be checking, not your own.
      </para>

    </sect2>
    <sect2>
      <title>Hooks do not propagate</title>

      <para id="x_1fc">In Mercurial, hooks are not revision controlled, and do
	not propagate when you clone, or pull from, a repository.  The

	control, as you can for example provide a
	<quote>standard</quote> installation of Mercurial on an NFS
	filesystem, and use a site-wide <filename role="special">~/.hgrc</filename> file to define hooks that all users will
	see.  However, this too has its limits; see below.
      </para>

    </sect2>
    <sect2>
      <title>Hooks can be overridden</title>

      <para id="x_200">Mercurial allows you to override a hook definition by
	redefining the hook.  You can disable it by setting its value

      <para id="x_201">If you deploy a system- or site-wide <filename
	  role="special">~/.hgrc</filename> file that defines some
	hooks, you should thus understand that your users can disable
	or override those hooks.
      </para>

    </sect2>
    <sect2>
      <title>Ensuring that critical hooks are run</title>

      <para id="x_202">Sometimes you may want to enforce a policy that you do not
	want others to be able to work around.  For example, you may

	that people pull have been automatically vetted.
      </para>

    </sect2>
  </sect1>
  <sect1>
    <title>Care with <literal>pretxn</literal> hooks in a
      shared-access repository</title>

    <para id="x_206">If you want to use hooks to do some automated work in a
      repository that a number of people have shared access to, you
      need to be careful in how you do this.
    </para>

    <para id="x_207">Mercurial only locks a repository when it is writing to the
      repository, and only the parts of Mercurial that write to the
      repository pay attention to locks.  Write locks are necessary to
      prevent multiple simultaneous writers from scribbling on each
      other's work, corrupting the repository.
    </para>

    <para id="x_208">Because Mercurial is careful with the order in which it
      reads and writes data, it does not need to acquire a lock when
      it wants to read data from the repository.  The parts of
      Mercurial that read from the repository never pay attention to
      locks.  This lockless reading scheme greatly increases
      performance and concurrency.
    </para>

    <para id="x_209">With great performance comes a trade-off, though, one which
      has the potential to cause you trouble unless you're aware of
      it.  To describe this requires a little detail about how
      Mercurial adds changesets to a repository and reads those
      changes.
    </para>

    <para id="x_20a">When Mercurial <emphasis>writes</emphasis> metadata, it
      writes it straight into the destination file.  It writes file
      data first, then manifest data (which contains pointers to the
      new file data), then changelog data (which contains pointers to
      the new manifest data).  Before the first write to each file, it
      stores a record of where the end of the file was in its
      transaction log.  If the transaction must be rolled back,
      Mercurial simply truncates each file back to the size it was
      before the transaction began.
    </para>

    <para id="x_20b">When Mercurial <emphasis>reads</emphasis> metadata, it reads
      the changelog first, then everything else.  Since a reader will
      only access parts of the manifest or file metadata that it can
      see in the changelog, it can never see partially written data.
    </para>

    <para id="x_20c">Some controlling hooks (<literal
	role="hook">pretxncommit</literal> and <literal
	role="hook">pretxnchangegroup</literal>) run when a
      transaction is almost complete. All of the metadata has been
      written, but Mercurial can still roll the transaction back and
      cause the newly-written data to disappear.
    </para>

    <para id="x_20d">If one of these hooks runs for long, it opens a window of
      time during which a reader can see the metadata for changesets
      that are not yet permanent, and should not be thought of as
      <quote>really there</quote>.  The longer the hook runs, the
      longer that window is open.
    </para>

    <sect2>
      <title>The problem illustrated</title>

      <para id="x_20e">In principle, a good use for the <literal
	  role="hook">pretxnchangegroup</literal> hook would be to
	automatically build and test incoming changes before they are
	accepted into a central repository.  This could let you
	guarantee that nobody can push changes to this repository that
	<quote>break the build</quote>. But if a client can pull
	changes while they're being tested, the usefulness of the test
	is zero; an unsuspecting someone can pull untested changes,
	potentially breaking their build.
      </para>

      <para id="x_20f">The safest technological answer to this challenge is to
	set up such a <quote>gatekeeper</quote> repository as
	<emphasis>unidirectional</emphasis>.  Let it take changes
	pushed in from the outside, but do not allow anyone to pull
	changes from it (use the <literal
	  role="hook">preoutgoing</literal> hook to lock it down).
	Configure a <literal role="hook">changegroup</literal> hook so
	that if a build or test succeeds, the hook will push the new
	changes out to another repository that people
	<emphasis>can</emphasis> pull from.
      </para>

      <para id="x_210">In practice, putting a centralised bottleneck like this in
	place is not often a good idea, and transaction visibility has
	nothing to do with the problem.  As the size of a
	project&emdash;and the time it takes to build and
	test&emdash;grows, you rapidly run into a wall with this
	<quote>try before you buy</quote> approach, where you have
	more changesets to test than time in which to deal with them.
	The inevitable result is frustration on the part of all
	involved.
      </para>

      <para id="x_211">An approach that scales better is to get people to build
	and test before they push, then run automated builds and tests
	centrally <emphasis>after</emphasis> a push, to be sure all is
	well.  The advantage of this approach is that it does not
	impose a limit on the rate at which the repository can accept
	changes.
      </para>

    </sect2>
  </sect1>
  <sect1 id="sec:hook:simple">
    <title>A short tutorial on using hooks</title>

    <para id="x_212">It is easy to write a Mercurial hook.  Let's start with a
      hook that runs when you finish a <command role="hg-cmd">hg

	parameter is named <literal>foo</literal>, the keyword
	argument for a Python hook will also be named
	<literal>foo</literal>, while the environment variable for an
	external hook will be named <literal>HG_FOO</literal>.
      </para>

    </sect2>
    <sect2>
      <title>Hook return values and activity control</title>

      <para id="x_225">A hook that executes successfully must exit with a status
	of zero if external, or return boolean <quote>false</quote> if

      <para id="x_226">For a hook that controls whether an activity can proceed,
	zero/false means <quote>allow</quote>, while
	non-zero/true/exception means <quote>deny</quote>.
      </para>

    </sect2>
    <sect2>
      <title>Writing an external hook</title>

      <para id="x_227">When you define an external hook in your <filename
	  role="special">~/.hgrc</filename> and the hook is run, its

	that may be run by a number of different users with differing
	environment variables set. In multi-user situations, you
	should not rely on environment variables being set to the
	values you have in your environment when testing the hook.
      </para>

    </sect2>
    <sect2>
      <title>Telling Mercurial to use an in-process hook</title>

      <para id="x_22b">The <filename role="special">~/.hgrc</filename> syntax
	for defining an in-process hook is slightly different than for

      <para id="x_22e">When Mercurial runs the <literal>commit.example</literal>
	hook, it imports <literal>mymodule.submodule</literal>, looks
	for the callable object named <literal>myhook</literal>, and
	calls it.
      </para>

    </sect2>
    <sect2>
      <title>Writing an in-process hook</title>

      <para id="x_22f">The simplest in-process hook does nothing, but illustrates
	the basic shape of the hook API:

	hook of the example below will prevent you from committing a
	changeset with a message that is less than ten bytes long.
      </para>

&interaction.hook.msglen.go;

    </sect2>
    <sect2>
      <title>Checking for trailing whitespace</title>

      <para id="x_232">An interesting use of a commit-related hook is to help you
	to write cleaner code.  A simple example of <quote>cleaner

	    role="hg-ext">acl</literal> hook will print enough
	  information to let you figure out why it is allowing or
	  forbidding pushes from specific users.
	</para>

      </sect3>
    </sect2>
    <sect2>
      <title><literal
	  role="hg-ext">bugzilla</literal>&emdash;integration with
	Bugzilla</title>

	  Bugzilla user name, nor does it have an entry in your
	  <literal role="rc-usermap">usermap</literal> that maps it to
	  a valid Bugzilla user name.
	</para>

      </sect3>
    </sect2>
    <sect2>
      <title><literal role="hg-ext">notify</literal>&emdash;send email
	notifications</title>

      <para id="x_26a">Although Mercurial's built-in web server provides RSS

      <para id="x_280">Note that changeset IDs are passed into Python hooks as
	hexadecimal strings, not the binary hashes that Mercurial's
	APIs normally use.  To convert a hash from hex to binary, use
	the <literal>bin</literal> function.
      </para>

    </sect2>
    <sect2>
      <title>External hook execution</title>

      <para id="x_281">An external hook is passed to the shell of the user
	running Mercurial. Features of that shell, such as variable

      <para id="x_284">If a hook exits with a status of zero, it is considered to
	have succeeded.  If it exits with a non-zero status, it is
	considered to have failed.
      </para>

    </sect2>
    <sect2>
      <title>Finding out where changesets come from</title>

      <para id="x_285">A hook that involves the transfer of changesets between a
	local repository and another may be able to find out

	  </listitem>
	  <listitem><para id="x_28a"><literal>bundle</literal>: Changesets are
	      being transferred to or from a bundle.
	    </para>
	  </listitem></itemizedlist>

      </sect3>
      <sect3 id="sec:hook:url">
	<title>Where changes are going&emdash;remote repository
	  URLs</title>

	<para id="x_28b">When possible, Mercurial will tell a hook the location

	  </listitem>
	  <listitem><para id="x_28f">Empty&emdash;no information could be
	      discovered about the remote client.
	    </para>
	  </listitem></itemizedlist>

      </sect3>
    </sect2>
  </sect1>
  <sect1>
    <title>Hook reference</title>

	  role="hook">prechangegroup</literal> (<xref
	  linkend="sec:hook:prechangegroup"/>), <literal
	  role="hook">pretxnchangegroup</literal> (<xref
	  linkend="sec:hook:pretxnchangegroup"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:commit">
      <title><literal role="hook">commit</literal>&emdash;after a new
	changeset is created</title>

      <para id="x_297">This hook is run after a new changeset has been created.

	  role="hook">precommit</literal> (<xref
	  linkend="sec:hook:precommit"/>), <literal
	  role="hook">pretxncommit</literal> (<xref
	  linkend="sec:hook:pretxncommit"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:incoming">
      <title><literal role="hook">incoming</literal>&emdash;after one
	remote changeset is added</title>

      <para id="x_29d">This hook is run after a pre-existing changeset has been

	  role="hook">prechangegroup</literal> (<xref
	  linkend="sec:hook:prechangegroup"/>), <literal
	  role="hook">pretxnchangegroup</literal> (<xref
	  linkend="sec:hook:pretxnchangegroup"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:outgoing">
      <title><literal role="hook">outgoing</literal>&emdash;after
	changesets are propagated</title>

      <para id="x_2a4">This hook is run after a group of changesets has been

      <para id="x_2aa">See also: <literal
	  role="hook">preoutgoing</literal> (<xref
	  linkend="sec:hook:preoutgoing"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:prechangegroup">
      <title><literal
	  role="hook">prechangegroup</literal>&emdash;before starting
	to add remote changesets</title>

	  role="hook">incoming</literal> (<xref
	  linkend="sec:hook:incoming"/>), <literal
	  role="hook">pretxnchangegroup</literal> (<xref
	  linkend="sec:hook:pretxnchangegroup"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:precommit">
      <title><literal role="hook">precommit</literal>&emdash;before
	starting to commit a changeset</title>

      <para id="x_2b2">This hook is run before Mercurial begins to commit a new

      <para id="x_2b8">See also: <literal role="hook">commit</literal>
	(<xref linkend="sec:hook:commit"/>), <literal
	  role="hook">pretxncommit</literal> (<xref
	  linkend="sec:hook:pretxncommit"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:preoutgoing">
      <title><literal role="hook">preoutgoing</literal>&emdash;before
	starting to propagate changesets</title>

      <para id="x_2b9">This hook is invoked before Mercurial knows the identities

      <para id="x_2be">See also: <literal
	  role="hook">outgoing</literal> (<xref
	  linkend="sec:hook:outgoing"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:pretag">
      <title><literal role="hook">pretag</literal>&emdash;before
	tagging a changeset</title>

      <para id="x_2bf">This controlling hook is run before a tag is created.  If

      <para id="x_2c5">See also: <literal role="hook">tag</literal>
	(<xref linkend="sec:hook:tag"/>)
      </para>
    </sect2>
    <sect2 id="sec:hook:pretxnchangegroup">
      <title><literal
	  role="hook">pretxnchangegroup</literal>&emdash;before
	completing addition of remote changesets</title>

	  role="hook">incoming</literal> (<xref
	  linkend="sec:hook:incoming"/>), <literal
	  role="hook">prechangegroup</literal> (<xref
	  linkend="sec:hook:prechangegroup"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:pretxncommit">
      <title><literal role="hook">pretxncommit</literal>&emdash;before
	completing commit of new changeset</title>

      <para id="x_2cf">This controlling hook is run before a

	access this repository, they will be able to see the
	almost-new changeset as if it is permanent.  This may lead to
	race conditions if you do not take steps to avoid them.
      </para>

      <para id="x_2d2">Parameters to this hook:
      </para>
      <itemizedlist>
	<listitem><para id="x_2d3"><literal>node</literal>: A changeset ID.  The
	    changeset ID of the newly committed changeset.
	  </para>
	</listitem>

      <para id="x_2d6">See also: <literal
	  role="hook">precommit</literal> (<xref
	  linkend="sec:hook:precommit"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:preupdate">
      <title><literal role="hook">preupdate</literal>&emdash;before
	updating or merging working directory</title>

      <para id="x_2d7">This controlling hook is run before an update

	  </para>
	</listitem></itemizedlist>

      <para id="x_2db">See also: <literal role="hook">update</literal>
	(<xref linkend="sec:hook:update"/>)</para>

    </sect2>
    <sect2 id="sec:hook:tag">
      <title><literal role="hook">tag</literal>&emdash;after tagging a
	changeset</title>

      <para id="x_2dc">This hook is run after a tag has been created.

      </para>

      <para id="x_2e2">See also: <literal role="hook">pretag</literal>
	(<xref linkend="sec:hook:pretag"/>)
      </para>

    </sect2>
    <sect2 id="sec:hook:update">
      <title><literal role="hook">update</literal>&emdash;after
	updating or merging working directory</title>

      <para id="x_2e3">This hook is run after an update or merge of the working

809:ef53d025f410

	you do not own (e.g. using <command role="hg-cmd">hg
	  pull</command> or <command role="hg-cmd">hg
	  incoming</command>), remember that it is the other
	repository's hooks you should be checking, not your own.
      </para>
    </sect2>

    <sect2>
      <title>Hooks do not propagate</title>

      <para id="x_1fc">In Mercurial, hooks are not revision controlled, and do
	not propagate when you clone, or pull from, a repository.  The

	control, as you can for example provide a
	<quote>standard</quote> installation of Mercurial on an NFS
	filesystem, and use a site-wide <filename role="special">~/.hgrc</filename> file to define hooks that all users will
	see.  However, this too has its limits; see below.
      </para>
    </sect2>

    <sect2>
      <title>Hooks can be overridden</title>

      <para id="x_200">Mercurial allows you to override a hook definition by
	redefining the hook.  You can disable it by setting its value

      <para id="x_201">If you deploy a system- or site-wide <filename
	  role="special">~/.hgrc</filename> file that defines some
	hooks, you should thus understand that your users can disable
	or override those hooks.
      </para>
    </sect2>

    <sect2>
      <title>Ensuring that critical hooks are run</title>

      <para id="x_202">Sometimes you may want to enforce a policy that you do not
	want others to be able to work around.  For example, you may

	that people pull have been automatically vetted.
      </para>

    </sect2>
  </sect1>

  <sect1 id="sec:hook:simple">
    <title>A short tutorial on using hooks</title>

    <para id="x_212">It is easy to write a Mercurial hook.  Let's start with a
      hook that runs when you finish a <command role="hg-cmd">hg

	parameter is named <literal>foo</literal>, the keyword
	argument for a Python hook will also be named
	<literal>foo</literal>, while the environment variable for an
	external hook will be named <literal>HG_FOO</literal>.
      </para>
    </sect2>

    <sect2>
      <title>Hook return values and activity control</title>

      <para id="x_225">A hook that executes successfully must exit with a status
	of zero if external, or return boolean <quote>false</quote> if

      <para id="x_226">For a hook that controls whether an activity can proceed,
	zero/false means <quote>allow</quote>, while
	non-zero/true/exception means <quote>deny</quote>.
      </para>
    </sect2>

    <sect2>
      <title>Writing an external hook</title>

      <para id="x_227">When you define an external hook in your <filename
	  role="special">~/.hgrc</filename> and the hook is run, its

	that may be run by a number of different users with differing
	environment variables set. In multi-user situations, you
	should not rely on environment variables being set to the
	values you have in your environment when testing the hook.
      </para>
    </sect2>

    <sect2>
      <title>Telling Mercurial to use an in-process hook</title>

      <para id="x_22b">The <filename role="special">~/.hgrc</filename> syntax
	for defining an in-process hook is slightly different than for

      <para id="x_22e">When Mercurial runs the <literal>commit.example</literal>
	hook, it imports <literal>mymodule.submodule</literal>, looks
	for the callable object named <literal>myhook</literal>, and
	calls it.
      </para>
    </sect2>

    <sect2>
      <title>Writing an in-process hook</title>

      <para id="x_22f">The simplest in-process hook does nothing, but illustrates
	the basic shape of the hook API:

	hook of the example below will prevent you from committing a
	changeset with a message that is less than ten bytes long.
      </para>

&interaction.hook.msglen.go;
    </sect2>

    <sect2>
      <title>Checking for trailing whitespace</title>

      <para id="x_232">An interesting use of a commit-related hook is to help you
	to write cleaner code.  A simple example of <quote>cleaner

	    role="hg-ext">acl</literal> hook will print enough
	  information to let you figure out why it is allowing or
	  forbidding pushes from specific users.
	</para>

      </sect3>    </sect2>

    <sect2>
      <title><literal
	  role="hg-ext">bugzilla</literal>&emdash;integration with
	Bugzilla</title>

	  Bugzilla user name, nor does it have an entry in your
	  <literal role="rc-usermap">usermap</literal> that maps it to
	  a valid Bugzilla user name.
	</para>

      </sect3>    </sect2>

    <sect2>
      <title><literal role="hg-ext">notify</literal>&emdash;send email
	notifications</title>

      <para id="x_26a">Although Mercurial's built-in web server provides RSS

      <para id="x_280">Note that changeset IDs are passed into Python hooks as
	hexadecimal strings, not the binary hashes that Mercurial's
	APIs normally use.  To convert a hash from hex to binary, use
	the <literal>bin</literal> function.
      </para>
    </sect2>

    <sect2>
      <title>External hook execution</title>

      <para id="x_281">An external hook is passed to the shell of the user
	running Mercurial. Features of that shell, such as variable

      <para id="x_284">If a hook exits with a status of zero, it is considered to
	have succeeded.  If it exits with a non-zero status, it is
	considered to have failed.
      </para>
    </sect2>

    <sect2>
      <title>Finding out where changesets come from</title>

      <para id="x_285">A hook that involves the transfer of changesets between a
	local repository and another may be able to find out

	  </listitem>
	  <listitem><para id="x_28a"><literal>bundle</literal>: Changesets are
	      being transferred to or from a bundle.
	    </para>
	  </listitem></itemizedlist>
      </sect3>

      <sect3 id="sec:hook:url">
	<title>Where changes are going&emdash;remote repository
	  URLs</title>

	<para id="x_28b">When possible, Mercurial will tell a hook the location

	  </listitem>
	  <listitem><para id="x_28f">Empty&emdash;no information could be
	      discovered about the remote client.
	    </para>
	  </listitem></itemizedlist>
      </sect3>
    </sect2>
  </sect1>
  <sect1>
    <title>Hook reference</title>

	  role="hook">prechangegroup</literal> (<xref
	  linkend="sec:hook:prechangegroup"/>), <literal
	  role="hook">pretxnchangegroup</literal> (<xref
	  linkend="sec:hook:pretxnchangegroup"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:commit">
      <title><literal role="hook">commit</literal>&emdash;after a new
	changeset is created</title>

      <para id="x_297">This hook is run after a new changeset has been created.

	  role="hook">precommit</literal> (<xref
	  linkend="sec:hook:precommit"/>), <literal
	  role="hook">pretxncommit</literal> (<xref
	  linkend="sec:hook:pretxncommit"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:incoming">
      <title><literal role="hook">incoming</literal>&emdash;after one
	remote changeset is added</title>

      <para id="x_29d">This hook is run after a pre-existing changeset has been

	  role="hook">prechangegroup</literal> (<xref
	  linkend="sec:hook:prechangegroup"/>), <literal
	  role="hook">pretxnchangegroup</literal> (<xref
	  linkend="sec:hook:pretxnchangegroup"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:outgoing">
      <title><literal role="hook">outgoing</literal>&emdash;after
	changesets are propagated</title>

      <para id="x_2a4">This hook is run after a group of changesets has been

      <para id="x_2aa">See also: <literal
	  role="hook">preoutgoing</literal> (<xref
	  linkend="sec:hook:preoutgoing"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:prechangegroup">
      <title><literal
	  role="hook">prechangegroup</literal>&emdash;before starting
	to add remote changesets</title>

	  role="hook">incoming</literal> (<xref
	  linkend="sec:hook:incoming"/>), <literal
	  role="hook">pretxnchangegroup</literal> (<xref
	  linkend="sec:hook:pretxnchangegroup"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:precommit">
      <title><literal role="hook">precommit</literal>&emdash;before
	starting to commit a changeset</title>

      <para id="x_2b2">This hook is run before Mercurial begins to commit a new

      <para id="x_2b8">See also: <literal role="hook">commit</literal>
	(<xref linkend="sec:hook:commit"/>), <literal
	  role="hook">pretxncommit</literal> (<xref
	  linkend="sec:hook:pretxncommit"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:preoutgoing">
      <title><literal role="hook">preoutgoing</literal>&emdash;before
	starting to propagate changesets</title>

      <para id="x_2b9">This hook is invoked before Mercurial knows the identities

      <para id="x_2be">See also: <literal
	  role="hook">outgoing</literal> (<xref
	  linkend="sec:hook:outgoing"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:pretag">
      <title><literal role="hook">pretag</literal>&emdash;before
	tagging a changeset</title>

      <para id="x_2bf">This controlling hook is run before a tag is created.  If

      <para id="x_2c5">See also: <literal role="hook">tag</literal>
	(<xref linkend="sec:hook:tag"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:pretxnchangegroup">
      <title><literal
	  role="hook">pretxnchangegroup</literal>&emdash;before
	completing addition of remote changesets</title>

	  role="hook">incoming</literal> (<xref
	  linkend="sec:hook:incoming"/>), <literal
	  role="hook">prechangegroup</literal> (<xref
	  linkend="sec:hook:prechangegroup"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:pretxncommit">
      <title><literal role="hook">pretxncommit</literal>&emdash;before
	completing commit of new changeset</title>

      <para id="x_2cf">This controlling hook is run before a

	access this repository, they will be able to see the
	almost-new changeset as if it is permanent.  This may lead to
	race conditions if you do not take steps to avoid them.
      </para>

      <para id="x_2d2">Parameters to this hook:</para>

      <itemizedlist>
	<listitem><para id="x_2d3"><literal>node</literal>: A changeset ID.  The
	    changeset ID of the newly committed changeset.
	  </para>
	</listitem>

      <para id="x_2d6">See also: <literal
	  role="hook">precommit</literal> (<xref
	  linkend="sec:hook:precommit"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:preupdate">
      <title><literal role="hook">preupdate</literal>&emdash;before
	updating or merging working directory</title>

      <para id="x_2d7">This controlling hook is run before an update

	  </para>
	</listitem></itemizedlist>

      <para id="x_2db">See also: <literal role="hook">update</literal>
	(<xref linkend="sec:hook:update"/>)</para>
    </sect2>

    <sect2 id="sec:hook:tag">
      <title><literal role="hook">tag</literal>&emdash;after tagging a
	changeset</title>

      <para id="x_2dc">This hook is run after a tag has been created.

      </para>

      <para id="x_2e2">See also: <literal role="hook">pretag</literal>
	(<xref linkend="sec:hook:pretag"/>)
      </para>
    </sect2>

    <sect2 id="sec:hook:update">
      <title><literal role="hook">update</literal>&emdash;after
	updating or merging working directory</title>

      <para id="x_2e3">This hook is run after an update or merge of the working