Introduction

The error about not being able to lock info/refs usually means Git tried to update reference metadata but found a conflicting lock file, bad permissions, or an inconsistent repository state. The fix is not to force random file deletion blindly, but to determine whether another Git process is still running and then clean up the stale lock or repository metadata safely.

What info/refs Is

info/refs is a reference listing used in certain Git serving and transport scenarios, especially with older or “dumb” HTTP-style repository access patterns. When Git updates it, it uses a lock file to avoid corruption from concurrent writers.

So the error is fundamentally about safe write coordination.

The Most Common Causes

Typical root causes are:

• another Git process is still updating the repository
• a previous Git process crashed and left a stale lock file behind
• repository permissions prevent Git from replacing the lock target
• the repository is being served or modified in a way that bypasses normal Git coordination

That means the first question is always whether the lock is active or stale.

Check for Concurrent Git Processes

If the repository is shared or hosted on a server, confirm that no active git fetch, git push, git gc, or maintenance job is still running.

On a Unix-like system, you might inspect process lists and server activity before touching lock files. If another Git process is genuinely active, removing the lock manually can corrupt the repository state.

Identify and Remove a Stale Lock Carefully

If you are sure no Git process is using the repository, inspect the Git directory for stale lock files.

Example in a bare repository:

find /path/to/repo.git -name '*.lock'

If the relevant lock file clearly belongs to a dead process, remove it:

rm /path/to/repo.git/info/refs.lock

Do this only after confirming the lock is stale.

Refresh Server-Side Reference Metadata

After cleaning a stale lock, it is often reasonable to regenerate the exported refs data:

git --git-dir=/path/to/repo.git update-server-info

That is especially relevant if the repository is being served in a way that relies on info/refs being up to date.

Check Ownership and Permissions

If Git cannot create or replace the lock file because of ownership problems, the same error can reappear immediately.

Useful checks include:

ls -ld /path/to/repo.git
ls -l /path/to/repo.git/info

Make sure the user running the Git operation owns or can write to the necessary files and directories.

Shared Repositories Need Process Discipline

This error often appears in repositories that are being manipulated directly by scripts, hooks, deployment jobs, or manual shell commands on the server.

If several tools write into the same bare repo, establish a clear operational rule:

• only Git commands update refs
• background maintenance is coordinated
• no ad hoc file edits inside the repo metadata

Git’s locking strategy works well when everything goes through Git. It works much less well when external tools partially modify the repo structure.

Common Pitfalls

The most common mistake is deleting lock files before checking whether a live Git process is still running. That can turn a temporary coordination problem into real repository corruption.

Another issue is fixing one stale lock but ignoring the permission problem that created the failure in the first place.

People also assume info/refs is just a harmless text file they can hand-edit. In practice, it is part of repository metadata management and should be handled through Git commands.

Finally, do not treat repeated lock errors as random. If they keep returning, there is usually a recurring workflow, permission, or hosting issue causing them.

Summary

• The error usually means Git could not safely lock info/refs for update.
• First confirm whether another Git process is still active.
• Remove stale lock files only when you are sure they are no longer in use.
• Check file ownership and repository write permissions.
• Use Git maintenance commands such as update-server-info instead of hand-editing repository metadata.