Introduction

This error usually means the hook script is running Git commands from a directory that is not actually the repository you think it is. In server-side hooks, especially post-update, the current working directory and Git environment are often different from an interactive shell session, so a plain git pull can easily run in the wrong place.

Why the Hook Sees the Wrong Repository

A post-update hook commonly runs inside a bare repository on the server. That is already important, because a bare repository has no working tree. If the script then tries to pull another repository without explicitly changing directories or using git -C, Git may interpret . relative to the hook environment and report:

fatal: not a git repository: '.'

The message is not saying Git is broken. It is saying the command does not have a valid repository context.

Do Not Rely on the Hook's Current Directory

The safest fix is to point Git at the target repository explicitly:

1#!/usr/bin/env bash
2set -euo pipefail
3
4target_repo="/srv/www/my-app"
5
6git -C "$target_repo" pull origin main

git -C changes to the given path for that Git command only. That is usually clearer and more reliable than assuming the hook starts in the right directory.

You can also do it manually:

1#!/usr/bin/env bash
2set -euo pipefail
3
4target_repo="/srv/www/my-app"
5
6cd "$target_repo"
7git pull origin main

Both approaches work, but git -C tends to be easier to read in hook scripts.

Know Which Repository You Actually Want to Update

There are two repositories in this kind of setup:

• the repository receiving the push, often bare
• the deployed working-tree repository you want to update

The hook lives in the first one, but the git pull should usually run in the second one. Mixing those two paths is the most common reason for this error.

Add debug logging when in doubt:

pwd
git rev-parse --is-bare-repository || true

This quickly shows where the script is running and whether Git thinks that location is a repository at all.

A Better Deployment Pattern

For deployment automation, git pull in a second repository is not always the cleanest design. A common alternative is to push into a bare repository and then check out the received commit into a working tree using --work-tree and --git-dir explicitly:

1#!/usr/bin/env bash
2set -euo pipefail
3
4git_dir="/srv/git/my-app.git"
5work_tree="/srv/www/my-app"
6
7git --git-dir="$git_dir" --work-tree="$work_tree" checkout -f main

This avoids maintaining a second repository that has to pull from the first one. It also makes the hook's repository context explicit.

Watch the Environment in Hooks

Hooks often run with a minimal environment:

• a different PATH
• different permissions
• no interactive shell setup
• different working directory assumptions

That means commands that work in your terminal can fail inside the hook unless paths and permissions are made explicit.

Common Pitfalls

The biggest mistake is calling git pull without changing into the target repository first. The hook's current directory is rarely the one you actually want.

Another issue is forgetting that post-update often runs inside a bare repo. A bare repo is not the same thing as a deployable working tree.

Teams also try to debug the hook only from the terminal instead of logging pwd, repository paths, and command output from the hook itself.

Summary

• The error usually means the hook is running Git in the wrong directory.
• Server-side hooks often execute inside a bare repository, not the deploy target.
• Use git -C, or --git-dir plus --work-tree, to point Git at the correct repository explicitly.
• Log the working directory and repository state when debugging hooks.
• For deployments, explicit checkout from a bare repo is often cleaner than making another repo run git pull.