HowTo: Apply client side hook restrictions automatically while cloning the repositories from Bitbucket Data Center

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

This document provides a guide to applying client-side hook restrictions automatically while cloning the repositories from the Bitbucket Data Center.

Problem

Git hooks are scripts that run on a cloned system. If they were automatically installed, then any repository that gets cloned would have full control of your system. This would be a security problem. If any person clones the repository and runs a git command, it will start executing the hook scripts.

Environment

Bitbucket Data Center - All versions

Solution

Below are some possible workarounds that will allow users to run client-side hook scripts while the user performs a clone or other git transactions. 

  • Users can create a shell script or a custom shell command to use to clone the repository, which both does the clone and sets up the hooks  or

  • Alternatively, the user may include a script inside the repository and tell the team to run it after they clone it. For instance, create a git-xyzclone command, which basically just requires putting a shell script named git-xyzclone in any directory on the path. For other repositories, the user can still use the regular git clone.

  • If the user maintains all the machines that people are cloning repositories from, the user can setup system-wide templates. From the git-init man page (also works with git-clone if the user is cloning an existing repo instead of creating a new one from scratch):

    1 2 3 4 5 6 7 8 --template=<template_directory>        Provide the directory from which templates will be used. The        default template directory is /usr/share/git-core/templates.        When specified, <template_directory> is used as the source of the        template files rather than the default. The template files include        some directory structure, some suggested "exclude patterns", and        copies of non-executing "hook" files. The suggested patterns and        hook files are all modifiable and extensible.  
  • User can modify the system-wide template directory (which defaults to /usr/share/git-core/templates), user can supply --template=<template_directory> on the command line when creating or cloning the repo, or user can configure the default template directory in the config file:

    1 2 [init]  templatedir = /path/to/templates

Updated on February 25, 2025

Still need help?

The Atlassian Community is here for you.