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

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 204 views

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.

Quick fix

Fixes fatal: error in revision walk: revision depth limit reached

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
  1. Set fetch-depth to 0 in GitHub Actions
  2. Configure Azure DevOps pipeline for full checkout
  3. Adjust GIT_DEPTH in GitLab CI
  4. Unshallow an existing clone
git — error
- uses: actions/checkout@v4
  with:
    fetch-depth: 0
fatal: error in revision walk: revision depth limit reached

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

Typical symptoms

  • CI/CD pipeline fails during git checkout step with revision walk error
  • Pull request builds fail while the main branch builds succeed
  • Error appears when checking out specific commits or tags
  • Builds work with recent commits but fail with older branches
  • The error mentions internal error in revision walk before the depth limit message
  • GitVersion, semantic-release, or similar tools fail to determine version
  • Azure DevOps or GitHub Actions checkout step fails with exit code 128

Common causes

  1. CI system configured with shallow clone depth that excludes the target commit
  2. Pull request based on a commit older than the fetch depth setting
  3. GitHub Actions checkout using default fetch-depth: 1
  4. Azure DevOps pipeline performing shallow fetch by default
  5. GitLab CI using default GIT_DEPTH that is too small
  6. Merge-base commit falling outside the shallow history window
  7. Referencing tags or commits not included in the shallow fetch
  8. Long-running feature branches diverging significantly from main

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

Frequently asked questions

What does "fatal: error in revision walk: revision depth limit reached" mean?
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/shallow file to indicate where the truncated history ends.
How do I fix "fatal: error in revision walk: revision depth limit reached"?
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 causes "fatal: error in revision walk: revision depth limit reached"?
CI system configured with shallow clone depth that excludes the target commit Pull request based on a commit older than the fetch depth setting GitHub Actions checkout using default fetch-depth: 1
Is the "fatal: error in revision walk: revision depth limit reached" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading