Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Git’s built-in reference-transaction hook reports low-level reference changes, not ready-made events such as “branch created” or “tag deleted.” Git Hooks Ext interprets those changes and dispatches named events, including branch-created, branch-updated, branch-deleted and head-switched. It is useful when automation needs to react to what a reference change means, rather than parse raw ref records itself.

What Git’s reference-transaction hook provides

Git’s official githooks manual says the hook is invoked by any Git command that performs reference updates. Git passes one argument identifying the transaction state—preparing, prepared, committed or aborted—and writes updates to standard input. Each record contains an old value, a new value and the full reference name:

<old-value> <new-value> <ref-name>

A transaction can invoke the hook at more than one state. The input describes reference changes; it does not directly say whether a user created a branch, deleted a tag, renamed a branch or switched HEAD. An integration that needs those meanings must interpret the records and account for the transaction lifecycle.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

What Git Hooks Ext adds

Git Hooks Ext (also referred to as ghe) sits above the raw hook interface. It recognizes reference changes and dispatches semantic events. Its documented event families include branches, remote branches, HEAD, tags, notes, stash and generic references. Examples include:

  • branch-created, branch-updated and branch-deleted
  • tag-deleted
  • head-switched, along with events for HEAD attachment and detachment

The available event names can be configured in Git configuration, exposed as classic hook filenames or inspected in dry-run output. This makes it possible to attach scripts to higher-level events without writing all the transaction parsing and classification yourself.

When callbacks run and how transaction state is handled

By default, Git Hooks Ext dispatches user hooks only when the reference transaction reaches committed. That timing avoids running callbacks for a change that has not committed. The extension also uses the earlier prepared stage to save a snapshot that can help recover old values when Git supplies zero values in the later payload.

Snapshots are kept in private state under the Git path, isolated by process and transaction payload, and consumed before event dispatch. If a transaction is aborted, its snapshot is discarded. If snapshot recovery fails, the project documents a fallback to the payload Git supplied; the extension does not reject the transaction because snapshot recovery failed.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Rename detection is an inference, not proof of intent

The reference-transaction hook reports reference changes, not the user action that caused them. Git Hooks Ext therefore treats rename detection as best-effort. A deletion and creation that point to the same object can resemble a rename, so the extension considers only unique matches within the same namespace. That reduces ambiguous matches, but cannot establish that a rename was what the user intended.

The project also reports that tested Git versions do not provide both sides of git branch -m through the underlying hook. If automation depends on reliably knowing that a rename occurred, treat the semantic rename event as a candidate inferred from the available changes, not a guaranteed record of user intent.

Worktree lifecycle events require the wrapper

Git Hooks Ext’s worktree lifecycle events are separate from its reference-transaction events. They are available when worktree operations go through the extension’s ghe worktree wrapper. Running ordinary git worktree commands directly bypasses that wrapper, so those commands do not emit the extension’s lifecycle events.

Git version and setup

The project documents Git 2.28 as the minimum version because the integration depends on the built-in reference-transaction hook. Its compatibility workflow covers Git 2.27–2.55, but that test range does not make Git 2.27 a supported minimum for this hook. Features and setup behavior can vary by Git version.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

According to the project documentation, installation detects the Git version: Git 2.54 or later uses config-based hooks, while Git 2.53 or older uses a legacy reference-transaction hook and prints migration instructions. Package availability and installation commands can change; consult the project’s current documentation for its installation page and instructions for Homebrew, Debian packages, container images and other distribution packages.

The documented quick start is to install the bridge, create an executable script and register that script for the desired semantic event with ghe add. The project also documents commands for listing events, checking setup with ghe doctor, and listing, showing or removing hook registrations. If your repository uses core.hooksPath, account for that setting when configuring hooks: Git’s hook lookup location may be set outside the repository’s usual hooks directory.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

When to use Git Hooks Ext

Use the built-in hook directly if raw old-value/new-value/ref records are enough and you are prepared to handle transaction states and classify changes in your own code. Git Hooks Ext is a better fit when scripts need named reference events and you want the extension to perform that interpretation.

  • Check that the target Git installation supports the hook; the project’s documented minimum is Git 2.28.
  • Decide whether best-effort rename inference is sufficient for your automation.
  • If you need worktree lifecycle callbacks, ensure worktree operations use ghe worktree rather than invoking git worktree directly.
  • Consider whether callbacks should run after commit; the extension defaults to dispatching them at committed.
  • Check the project’s current setup instructions for your Git version and any existing core.hooksPath configuration.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.