Git Hooks Users Guide

This document provides a quick reference towards using AdaCore's "Git Hooks", which are the scripts used to manage our git repositories, when new commits get pushed. These scripts are typically responsible for pre-commit checks, and email notifications.

Enabling the hooks

The hooks have been designed to work with both bare and non-bare repositories. But typical usage will be with bare repositories.

o enable the hooks, an administrator needs to replace the "hooks" directory in your git repository by a link to the /hooks directory from a git-hooks checkout, and configure them as outlined below.

Minimum Configuration

The following config options must be set for all repositories. Updates of any kind will be rejected with an appropriate error message until minimum configuration is satisfied.

See below for a description of these config options.


Configuration File location

The hooks configuration is loaded from a file named project.config in branch refs/meta/config. This file follows the same format as the various git "config" files (Eg. $HOME/.gitconfig).

To update your repository's configuration, you will need to do the following:

Configuration Options for General Use

The following config options are available for general use:

    no-emails = /refs/heads/fsf-.*, /refs/heads/thirdparty

    no-precommit-check = /refs/heads/fsf-.*, /refs/heads/thirdparty

    no-rh-style-checks = /refs/heads/fsf-.*, /refs/heads/thirdparty

Configuration Options for Debugging

The following config options are recognized, but are only meant to be used for debugging/testing purposes. They should not be used during normal operations.

Pre-commit Checks

Pre-commit Checks on the Revision History

The hooks verify that the revision histories of all new commits being pushed comply with the rules defined below. This step is skipped for any commit whose revision history contains the '(no-rh-check)' sequence.

Rules enforced on the revision logs:

      | The subject of my commit - no other explanation required.

      | The subject of my commit
      | This is what this commit does.

      | The subject of my commit
      | This is what this commit does, but an empty line is missing
      | between the subject and this description.

Filename Collisions Pre-commit Check

On Operating Systems such as Darwin or Windows, where the File System is typically case-insensitive, having two files whose name only differ in the casing (Eg: "hello.txt" and "Hello.txt", or "dir/hello.txt" vs "DIR/hello.txt") can cause a lot of confusion. To avoid this, the hooks will reject any commit where such name collision occurs.

This check is disabled on the branches matching the config value, or if a valid $HOME/.no_cvs_check file is found (see below).

Pre-commit Checks on the Differences Introduced by the Commit

This is the usual "style check" performed by the cvs_check program, maintained by the infosys team.

Note that the program verifies the entire contents of the files being modified, not just the modified parts.

Controlling the Pre-commit Checks

/!\ Despite the use of very similar names, note the fairly important difference in scope between the config option, and the no-precommit-check git attribute! (see below)

By default, the pre-commit checks are turned on for all commits of all branches. The following controls are available to tailor the hooks' behavior regarding this check:

Email Notifications

In general, developers are notified via email whenever a change is pushed to the repository. This section describes the policy used to determine which emails are being sent.

The Summary Email

The purpose of this email is to give a quick overview of what has changed.


The Summary Email is composed of two sections:

  1. A short description of what has changed. For instance, if a tag was created, it will explain what kind of tag was created, what the associated revision log was, and what commit it points to.
  2. Optionally, a list of commits which have been lost and/or added.

Sending Policy

The general policy is to send the Summary Email for all updates in order to inform its developers about the change. However, there are a number of situations where the email would bring little information to the Commit Emails already sent out:

Filing Policy

Normally, this email is not used for filing purposes (ie, a copy is not even sent to file-ci@), as we are more interested in filing the individual commits than the summary.

However, it is interesting to file those emails in the following cases:

In those cases, the revision log attached to those tags may contain a TN, which means this event deserves filing.

In either case, a Diff: marker is always added before the section summarizing the list of commits that were lost and/or added, making sure that this part of the email never gets filed, as the commits themselves are already getting filed.

The Commit Emails


The subject of that email is the commit's subject and its contents is roughly what the git show command would display.

Sending Policy

The Commit Email is always sent, unless the commit is found to exist in a branch matching the configuration.

Filing Policy

This email is always bcc'd to file-ci@. Note that this list must not appear in any explicit To:/Cc: header, as we want to prevent any replies from being sent there.

Retiring Old Branches

The recommended method for retiring a branch which is no longer useful is the following:

By using the naming suggested for the tag, the hooks will ensure that the branch never gets accidently recreated. This would otherwise happen if a developer did not know that the branch was deleted, still had that branch locally in his repository, and tried to push his change as usual.

The use of the retired/ namespace for those tags also helps standardizing the location where those tags are created.

And the use of a tag allows everyone to determine the latest state of that branch prior to its retirement.

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.