Mercurial > hg
diff mercurial/help/config.txt @ 33170:26c49ed51a69 stable 4.2.2
help: cleanup grammar in the hooks section
author | Matt Harbison <matt_harbison@yahoo.com> |
---|---|
date | Tue, 04 Jul 2017 22:58:21 -0400 |
parents | de86a6872d06 |
children | 85d1ac011582 |
line wrap: on
line diff
--- a/mercurial/help/config.txt Tue Jul 04 10:18:44 2017 -0400 +++ b/mercurial/help/config.txt Tue Jul 04 22:58:21 2017 -0400 @@ -861,31 +861,31 @@ Most hooks are run with environment variables set that give useful additional information. For each hook below, the environment variables -it is passed are listed with names of the form ``$HG_foo``. The +it is passed are listed with names in the form ``$HG_foo``. The ``$HG_HOOKTYPE`` and ``$HG_HOOKNAME`` variables are set for all hooks. -their respectively contains the type of hook which triggered the run and -the full name of the hooks in the config. In the example about this will +They contain the type of hook which triggered the run and the full name +of the hook in the config, respectively. In the example above, this will be ``$HG_HOOKTYPE=incoming`` and ``$HG_HOOKNAME=incoming.email``. ``changegroup`` - Run after a changegroup has been added via push, pull or unbundle. ID of the - first new changeset is in ``$HG_NODE`` and last in ``$HG_NODE_LAST``. URL - from which changes came is in ``$HG_URL``. + Run after a changegroup has been added via push, pull or unbundle. The ID of + the first new changeset is in ``$HG_NODE`` and last is in ``$HG_NODE_LAST``. + The URL from which changes came is in ``$HG_URL``. ``commit`` - Run after a changeset has been created in the local repository. ID + Run after a changeset has been created in the local repository. The ID of the newly created changeset is in ``$HG_NODE``. Parent changeset IDs are in ``$HG_PARENT1`` and ``$HG_PARENT2``. ``incoming`` Run after a changeset has been pulled, pushed, or unbundled into the local repository. The ID of the newly arrived changeset is in - ``$HG_NODE``. URL that was source of changes came is in ``$HG_URL``. + ``$HG_NODE``. The URL that was source of the changes is in ``$HG_URL``. ``outgoing`` - Run after sending changes from local repository to another. ID of - first changeset sent is in ``$HG_NODE``. Source of operation is in - ``$HG_SOURCE``; Also see :hg:`help config.hooks.preoutgoing` hook. + Run after sending changes from the local repository to another. The ID of + first changeset sent is in ``$HG_NODE``. The source of operation is in + ``$HG_SOURCE``. Also see :hg:`help config.hooks.preoutgoing`. ``post-<command>`` Run after successful invocations of the associated command. The @@ -917,93 +917,94 @@ ``prechangegroup`` Run before a changegroup is added via push, pull or unbundle. Exit - status 0 allows the changegroup to proceed. Non-zero status will - cause the push, pull or unbundle to fail. URL from which changes + status 0 allows the changegroup to proceed. A non-zero status will + cause the push, pull or unbundle to fail. The URL from which changes will come is in ``$HG_URL``. ``precommit`` Run before starting a local commit. Exit status 0 allows the - commit to proceed. Non-zero status will cause the commit to fail. + commit to proceed. A non-zero status will cause the commit to fail. Parent changeset IDs are in ``$HG_PARENT1`` and ``$HG_PARENT2``. ``prelistkeys`` Run before listing pushkeys (like bookmarks) in the - repository. Non-zero status will cause failure. The key namespace is + repository. A non-zero status will cause failure. The key namespace is in ``$HG_NAMESPACE``. ``preoutgoing`` Run before collecting changes to send from the local repository to - another. Non-zero status will cause failure. This lets you prevent - pull over HTTP or SSH. Also prevents against local pull, push - (outbound) or bundle commands, but not effective, since you can - just copy files instead then. Source of operation is in - ``$HG_SOURCE``. If "serve", operation is happening on behalf of remote - SSH or HTTP repository. If "push", "pull" or "bundle", operation - is happening on behalf of repository on same system. + another. A non-zero status will cause failure. This lets you prevent + pull over HTTP or SSH. It can also prevent propagating commits (via + local pull, push (outbound) or bundle commands), but not completely, + since you can just copy files instead. The source of operation is in + ``$HG_SOURCE``. If "serve", the operation is happening on behalf of a remote + SSH or HTTP repository. If "push", "pull" or "bundle", the operation + is happening on behalf of a repository on same system. ``prepushkey`` Run before a pushkey (like a bookmark) is added to the - repository. Non-zero status will cause the key to be rejected. The + repository. A non-zero status will cause the key to be rejected. The key namespace is in ``$HG_NAMESPACE``, the key is in ``$HG_KEY``, the old value (if any) is in ``$HG_OLD``, and the new value is in ``$HG_NEW``. ``pretag`` Run before creating a tag. Exit status 0 allows the tag to be - created. Non-zero status will cause the tag to fail. ID of - changeset to tag is in ``$HG_NODE``. Name of tag is in ``$HG_TAG``. Tag is - local if ``$HG_LOCAL=1``, in repository if ``$HG_LOCAL=0``. + created. A non-zero status will cause the tag to fail. The ID of the + changeset to tag is in ``$HG_NODE``. The name of tag is in ``$HG_TAG``. The + tag is local if ``$HG_LOCAL=1``, or in the repository if ``$HG_LOCAL=0``. ``pretxnopen`` Run before any new repository transaction is open. The reason for the - transaction will be in ``$HG_TXNNAME`` and a unique identifier for the + transaction will be in ``$HG_TXNNAME``, and a unique identifier for the transaction will be in ``HG_TXNID``. A non-zero status will prevent the transaction from being opened. ``pretxnclose`` Run right before the transaction is actually finalized. Any repository change will be visible to the hook program. This lets you validate the transaction - content or change it. Exit status 0 allows the commit to proceed. Non-zero + content or change it. Exit status 0 allows the commit to proceed. A non-zero status will cause the transaction to be rolled back. The reason for the - transaction opening will be in ``$HG_TXNNAME`` and a unique identifier for + transaction opening will be in ``$HG_TXNNAME``, and a unique identifier for the transaction will be in ``HG_TXNID``. The rest of the available data will - vary according the transaction type. New changesets will add ``$HG_NODE`` (id - of the first added changeset), ``$HG_NODE_LAST`` (id of the last added - changeset), ``$HG_URL`` and ``$HG_SOURCE`` variables, bookmarks and phases - changes will set ``HG_BOOKMARK_MOVED`` and ``HG_PHASES_MOVED`` to ``1``, etc. + vary according the transaction type. New changesets will add ``$HG_NODE`` + (the ID of the first added changeset), ``$HG_NODE_LAST`` (the ID of the last + added changeset), ``$HG_URL`` and ``$HG_SOURCE`` variables. Bookmark and + phase changes will set ``HG_BOOKMARK_MOVED`` and ``HG_PHASES_MOVED`` to ``1`` + respectively, etc. ``txnclose`` Run after any repository transaction has been committed. At this point, the transaction can no longer be rolled back. The hook will run - after the lock is released. See :hg:`help config.hooks.pretxnclose` docs for + after the lock is released. See :hg:`help config.hooks.pretxnclose` for details about available variables. ``txnabort`` Run when a transaction is aborted. See :hg:`help config.hooks.pretxnclose` - docs for details about available variables. + for details about available variables. ``pretxnchangegroup`` Run after a changegroup has been added via push, pull or unbundle, but before - the transaction has been committed. Changegroup is visible to hook program. - This lets you validate incoming changes before accepting them. Passed the ID - of the first new changeset in ``$HG_NODE`` and last in ``$HG_NODE_LAST``. - Exit status 0 allows the transaction to commit. Non-zero status will cause - the transaction to be rolled back and the push, pull or unbundle will fail. - URL that was source of changes is in ``$HG_URL``. + the transaction has been committed. The changegroup is visible to the hook + program. This allows validation of incoming changes before accepting them. + The ID of the first new changeset is in ``$HG_NODE`` and last is in + ``$HG_NODE_LAST``. Exit status 0 allows the transaction to commit. A non-zero + status will cause the transaction to be rolled back, and the push, pull or + unbundle will fail. The URL that was the source of changes is in ``$HG_URL``. ``pretxncommit`` - Run after a changeset has been created but the transaction not yet - committed. Changeset is visible to hook program. This lets you - validate commit message and changes. Exit status 0 allows the - commit to proceed. Non-zero status will cause the transaction to - be rolled back. ID of changeset is in ``$HG_NODE``. Parent changeset - IDs are in ``$HG_PARENT1`` and ``$HG_PARENT2``. + Run after a changeset has been created, but before the transaction is + committed. The changeset is visible to the hook program. This allows + validation of the commit message and changes. Exit status 0 allows the + commit to proceed. A non-zero status will cause the transaction to + be rolled back. The ID of the new changeset is in ``$HG_NODE``. The parent + changeset IDs are in ``$HG_PARENT1`` and ``$HG_PARENT2``. ``preupdate`` Run before updating the working directory. Exit status 0 allows - the update to proceed. Non-zero status will prevent the update. - Changeset ID of first new parent is in ``$HG_PARENT1``. If merge, ID - of second new parent is in ``$HG_PARENT2``. + the update to proceed. A non-zero status will prevent the update. + The changeset ID of first new parent is in ``$HG_PARENT1``. If updating to a + merge, the ID of second new parent is in ``$HG_PARENT2``. ``listkeys`` Run after listing pushkeys (like bookmarks) in the repository. The @@ -1017,20 +1018,20 @@ value is in ``$HG_NEW``. ``tag`` - Run after a tag is created. ID of tagged changeset is in ``$HG_NODE``. - Name of tag is in ``$HG_TAG``. Tag is local if ``$HG_LOCAL=1``, in - repository if ``$HG_LOCAL=0``. + Run after a tag is created. The ID of the tagged changeset is in ``$HG_NODE``. + The name of tag is in ``$HG_TAG``. The tag is local if ``$HG_LOCAL=1``, or in + the repository if ``$HG_LOCAL=0``. ``update`` - Run after updating the working directory. Changeset ID of first - new parent is in ``$HG_PARENT1``. If merge, ID of second new parent is - in ``$HG_PARENT2``. If the update succeeded, ``$HG_ERROR=0``. If the - update failed (e.g. because conflicts not resolved), ``$HG_ERROR=1``. + Run after updating the working directory. The changeset ID of first + new parent is in ``$HG_PARENT1``. If updating to a merge, the ID of second new + parent is in ``$HG_PARENT2``. If the update succeeded, ``$HG_ERROR=0``. If the + update failed (e.g. because conflicts were not resolved), ``$HG_ERROR=1``. .. note:: It is generally better to use standard hooks rather than the - generic pre- and post- command hooks as they are guaranteed to be + generic pre- and post- command hooks, as they are guaranteed to be called in the appropriate contexts for influencing transactions. Also, hooks like "commit" will be called in all contexts that generate a commit (e.g. tag) and not just the commit command.