View on
MetaCPAN is shutting down
For details read Perl NOC. After June 25th this page will redirect to
Gustavo Leite de Mendonça Chaves > Git-Hooks > Git::Hooks::CheckAcls



Annotate this POD


View/Report Bugs
Module Version: v2.9.6   Source  


Git::Hooks::CheckAcls - [DEPRECATED] Git::Hooks plugin for branch/tag access control


version 2.9.6


As a Git::Hooks plugin you don't use this Perl module directly. Instead, you may configure it in a Git configuration file like this:


    # Enable the plugin
    plugin = CheckAcls

    # These users are exempt from all checks
    admin = joe molly

  [githooks "checkacls"]

    # Any user can create, rewrite, update, and delete branches prefixed with
    # their own usernames.
    acl = ^.      CRUD ^refs/heads/{USER}/

    # Any user can update any branch.
    acl = ^.      U    ^refs/heads/


This plugin is deprecated. Please, use the Git::Hooks::CheckReference plugin instead.

This Git::Hooks plugin hooks itself to the hooks below to guarantee that only allowed users can push commits and tags to specific branches.

To enable it you should add it to the githooks.plugin configuration option:

      plugin = CheckAcls


Git::Hooks::CheckAcls - [DEPRECATED] Git::Hooks plugin for branch/tag access control


The plugin is configured by the following git options under the githooks.checkacls subsection.

It can be disabled for specific references via the githooks.ref and githooks.noref options about which you can read in the Git::Hooks documentation.

acl ACL

The authorization specification for a repository is defined by the set of ACLs defined by this option. Each ACL specify 'who' has 'what' kind of access to which refs, by means of a string with three components separated by spaces:

    who what refs

By default, nobody has access to anything, except the users specified by the githooks.admin configuration option. During an update, all the ACLs are processed in the order defined by the git config --list command. The first ACL matching the authenticated username and the affected reference name (usually a branch) defines what operations are allowed. If no ACL matches username and reference name, then the operation is denied.

The 'who' component specifies to which users this ACL gives access. It can be specified as a username, a groupname, or a regex, like the githooks.admin configuration option.

The 'what' component specifies what kind of access to allow. It's specified as a string of one or more of the following opcodes:

You may specify that the user has no access whatsoever to the references by using a single hyphen (-) as the what component.

The 'refs' component specifies which refs this ACL applies to. It can be specified in one of these formats:

The ACL specification can embed strings in the format {VAR}. These strings are substituted by the corresponding environment's variable VAR value. This interpolation occurs before the components are split and processed.

This is useful, for instance, if you want developers to be restricted in what they can do to official branches but to have complete control with their own branch namespace.

    [githooks "checkacls"]
      acl = ^. CRUD ^refs/heads/{USER}/
      acl = ^. U    ^refs/heads

In this example, every user (^.) has complete control (CRUD) to the branches below "refs/heads/{USER}". Supposing the environment variable USER contains the user's login name during a "pre-receive" hook. For all other branches (^refs/heads) the users have only update (U) rights.



Gustavo L. de M. Chaves <>


This software is copyright (c) 2018 by CPqD <>.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

syntax highlighting: