How to fix fatal: error in revision walk: revision depth limit reached in Git

GitINTERMEDIATEMEDIUM

This error occurs in CI/CD pipelines when Git cannot traverse the commit history due to shallow clone depth restrictions. The checkout commit exists outside the fetched history window, preventing Git from completing the revision walk.

What this error means

The "fatal: error in revision walk: revision depth limit reached" error indicates that Git's internal traversal of the commit graph has been stopped because it reached the boundary of a shallow clone's history. When you perform a shallow clone using `git clone --depth N` or when CI/CD systems like GitHub Actions, GitLab CI, or Azure DevOps use shallow fetches, only the most recent N commits are downloaded. Git stores "shallow boundary" markers in the `.git/shallow` file to indicate where the truncated history ends. During operations that require walking through commit history (such as checkouts, merges, or revision lookups), Git may need to access commits that exist beyond this boundary. When it reaches the depth limit and cannot find the required commit in the local history, it raises this fatal error. This commonly occurs in CI pipelines when: - A pull request is based on an older commit that falls outside the shallow fetch depth - The merge-base between branches is older than the fetch depth - Tags or specific commits being referenced are not within the fetched history window

How to fix "fatal: error in revision walk: revision depth limit reached"

1Set fetch-depth to 0 in GitHub Actions

If you're using GitHub Actions, modify your checkout step to fetch the complete history:

yaml

- uses: actions/checkout@v4
  with:
    fetch-depth: 0

Setting fetch-depth: 0 tells the checkout action to fetch all commits instead of performing a shallow clone. This ensures all commits, branches, and tags are available for the revision walk.

For large repositories where full clone time is a concern, you can try a deeper but not complete fetch:

yaml

- uses: actions/checkout@v4
  with:
    fetch-depth: 100

2Configure Azure DevOps pipeline for full checkout

For Azure DevOps pipelines, add an explicit checkout step with fetchDepth set to 0:

yaml

steps:
  - checkout: self
    fetchDepth: 0
    clean: true

Azure DevOps pipelines created after September 2022 default to shallow clones. This change was made for performance, but it breaks tools that need full history access.

For classic pipelines, navigate to the repository settings in the pipeline editor and set "Shallow fetch" to disabled or increase the depth value.

3Adjust GIT_DEPTH in GitLab CI

In GitLab CI, set the GIT_DEPTH variable to 0 for a full clone:

yaml

variables:
  GIT_DEPTH: 0

build:
  script:
    - echo "Full history available"

You can also set this globally in your project settings under Settings > CI/CD > General pipelines > Git shallow clone.

For specific jobs that need full history while keeping others fast:

yaml

versioning:
  variables:
    GIT_DEPTH: 0
  script:
    - git describe --tags

quick-build:
  # Uses default shallow clone
  script:
    - npm run build

4Unshallow an existing clone

If you're in a CI environment with an existing shallow clone and cannot modify the pipeline configuration, you can unshallow the repository during the build:

bash

# Convert shallow clone to full clone
git fetch --unshallow

# Or deepen incrementally if full history is too large
git fetch --deepen=100

Add this to your pipeline script before commands that require history traversal:

yaml

# GitHub Actions
- name: Unshallow repository
  run: git fetch --unshallow

# GitLab CI
before_script:
  - git fetch --unshallow || true

The || true fallback prevents failure if the repository is already unshallowed.

5Fetch specific refs when full clone is too slow

For very large repositories where full clone is impractical, fetch only the specific refs you need:

bash

# Fetch the specific branch and its history
git fetch origin main --depth=50

# Fetch tags if needed for versioning
git fetch --tags

# Fetch the merge-base explicitly
git fetch origin $(git merge-base HEAD origin/main)

In GitHub Actions, you can fetch specific refs:

yaml

- uses: actions/checkout@v4
  with:
    fetch-depth: 50
    ref: ${{ github.event.pull_request.head.sha }}

- name: Fetch base branch
  run: |
    git fetch origin ${{ github.base_ref }}:refs/remotes/origin/${{ github.base_ref }}

6Debug the shallow clone state

To understand what history is available in your shallow clone, use these diagnostic commands:

bash

# Check if repository is shallow
git rev-parse --is-shallow-repository

# View shallow boundaries
cat .git/shallow

# Count available commits
git rev-list --count HEAD

# Check depth of current branch
git log --oneline | wc -l

# See what refs are available
git branch -a
git tag -l

If the commit you need is not in the output of git log, you'll need to deepen or unshallow the clone.

Advanced notes

### Understanding Revision Walks

A revision walk is Git's internal process of traversing the commit graph, starting from a given commit and walking backwards through parent commits. Commands like git log, git merge-base, git describe, and git checkout all perform revision walks internally.

In a shallow clone, the .git/shallow file contains commit hashes that mark the boundary of the fetched history. These commits are treated as if they have no parents, even though they do in the full repository. When a revision walk reaches these boundary commits and needs to continue, it fails with the depth limit error.

### Impact on CI/CD Tools

Several common CI/CD tools require full or deep history access:

- GitVersion/Semantic Release: Need history to calculate versions based on commits
- Changelog generators: Require commit history to generate release notes
- git describe: Needs tag history to determine version from tags
- Merge conflict detection: May need to find common ancestors

For these tools, fetch-depth: 0 is often mandatory.

### Performance Trade-offs

Full clones can be slow for large repositories. Consider these strategies:

1. Blobless clones: git clone --filter=blob:none fetches commits and trees but defers blob downloads
2. Treeless clones: git clone --filter=tree:0 fetches only commits initially
3. Sparse checkouts: Combine with --sparse to limit checked-out files

These partial clone features require Git 2.22+ and server-side support.

### Monorepo Considerations

Large monorepos often have complex branching strategies where the merge-base between feature branches and main can be hundreds or thousands of commits back. For these repositories:

- Consider using build caches instead of git history for dependency checking
- Use partial clones with filters instead of shallow clones
- Set up dedicated CI runners with persistent git caches

### Bitbucket Pipelines

Bitbucket Pipelines also defaults to shallow clones. To fetch full history:

yaml

clone:
  depth: full

Or set a specific depth:

yaml

clone:
  depth: 50

How to fix fatal: error in revision walk: revision depth limit reached in Git

What this error means

Typical symptoms

Common causes

How to fix "fatal: error in revision walk: revision depth limit reached"

Advanced notes

Related errors

Official resources & further reading