How to fix fatal: error in object: unshallow in Git

GitINTERMEDIATEMEDIUMUpdated Dec 2, 2025· 246 views

The "git fetch --unshallow" command fails when converting a shallow clone to a full repository. This typically occurs due to repository corruption, attempting to unshallow an already-complete repository, or CI/CD pipeline configuration issues.

Quick fix

Fixes fatal: error in object: unshallow

git rev-parse --is-shallow-repository
  1. Verify if repository is already shallow
  2. Fix corrupted shallow repository objects
  3. Use alternative depth specification
  4. Fetch all branches after unshallowing
git — error
git rev-parse --is-shallow-repository
fatal: error in object: unshallow

What this error means

The "git fetch --unshallow" error occurs when Git cannot successfully convert a shallow clone into a full repository with complete history. A shallow clone is a repository that contains only a limited number of recent commits (specified by --depth), which speeds up cloning but lacks the full commit history. When you run "git fetch --unshallow", Git attempts to fetch all missing commits and objects from the remote repository to convert the shallow clone into a complete one. This operation can fail for several reasons: the repository may already be complete (not shallow), there may be corrupted objects in the repository, or network/remote issues may interrupt the fetch process. This error is particularly common in CI/CD environments where shallow clones are used by default to speed up pipeline execution, but tools or scripts later require access to the full repository history for operations like versioning, changelog generation, or branch analysis.

Typical symptoms

  • Command exits with "fatal: --unshallow on a complete repository does not make sense"
  • Error message "fatal: error in object: unshallow [SHA-1]" appears during fetch
  • CI/CD pipeline fails with exit code 128 or 255 during git fetch step
  • GitVersion or similar tools report "Cannot find commit [SHA]. Please ensure that the repository is an unshallow clone"
  • git fetch --unshallow hangs or times out on large repositories
  • Network errors or "early EOF" messages during unshallow operation

Common causes

  1. Attempting to unshallow a repository that is already a full clone (most common)
  2. Corrupted objects in the shallow repository's object database
  3. CI/CD system configured with shallow clone but tool requires full history
  4. Network interruption during previous shallow fetch operations
  5. Repository has case-sensitive branch/tag name conflicts (Azure DevOps)
  6. Shallow boundary metadata is inconsistent or damaged
  7. Remote repository is unavailable or has connectivity issues
  8. Large repository size causing timeout before completion

How to fix "fatal: error in object: unshallow"

1Verify if repository is already shallow

Before attempting to unshallow, check if your repository is actually shallow:

bash
git rev-parse --is-shallow-repository

If this returns false, your repository is already complete and doesn't need unshallowing. This is the most common cause of the error.

For Git versions before 2.14, check for the existence of the shallow file:

bash
ls -la .git/shallow

If the file doesn't exist, you have a full clone.

2Fix corrupted shallow repository objects

If you get "fatal: error in object: unshallow", the repository's object database may be corrupted. Run a repack to rebuild it:

bash
git repack -d

For more thorough repair:

bash
git repack -aldf

After repacking, try unshallowing again:

bash
git fetch --unshallow
3Use alternative depth specification

Instead of --unshallow, specify a very large depth value (effectively infinite):

bash
git fetch --depth=2147483647

This is the maximum signed 32-bit integer value and tells Git to fetch all available history. This approach can be more reliable than --unshallow in some scenarios.

4Fetch all branches after unshallowing

After successfully unshallowing, you may still only have one branch. To fetch all remote branches, update your remote configuration:

bash
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git fetch origin

Or for a one-time fetch of all branches:

bash
git fetch origin '+refs/heads/*:refs/remotes/origin/*'
5Fix CI/CD pipeline configuration

If this error occurs in CI/CD pipelines, configure your system to perform full clones from the start.

GitHub Actions:

yaml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Full clone

GitLab CI:

yaml
variables:
  GIT_DEPTH: 0  # Or use a large number like 1000

Azure DevOps:

yaml
- checkout: self
  fetchDepth: 0

CircleCI (.circleci/config.yml):

yaml
checkout:
  post:
    - git fetch --unshallow || true

The || true ensures the build continues even if unshallow fails because the repo is already complete.

6Handle case-sensitive branch conflicts (Azure DevOps)

Azure DevOps may have issues with branches/tags that differ only in case (e.g., "Release/1.0.0" vs "release/1.0.0"). Remove conflicting branches:

bash
# List all branches
git branch -a

# Delete conflicting remote branches (adjust as needed)
git push origin --delete Task/branch-name

# Keep only lowercase versions

This resolves issues introduced by Azure DevOps case sensitivity changes.

7Perform incremental deepening for large repositories

For very large repositories where --unshallow times out, deepen the clone incrementally:

bash
git fetch --depth=100
git fetch --depth=500
git fetch --depth=1000
git fetch --unshallow

Each step adds more history. If a step fails, the existing clone remains intact and you can retry.

8Re-clone as full repository if all else fails

If the shallow repository is irreparably damaged, perform a fresh full clone:

bash
# Backup any local changes
git diff > local-changes.patch
git diff --staged > staged-changes.patch

# Clone fresh without depth restriction
cd ..
rm -rf old-repo
git clone https://github.com/user/repo.git

# Apply backed-up changes if needed
cd repo
git apply ../local-changes.patch

Use --no-single-branch if you need all branches from the start:

bash
git clone --no-single-branch https://github.com/user/repo.git

Advanced notes

Shallow Clone Internals:
Git stores shallow clone information in .git/shallow, which lists commit SHAs that form the "shallow boundary" - commits whose parents have been deliberately excluded. The commit objects themselves are unchanged, but Git ignores parent connections beyond this boundary.

When to Use Shallow Clones:
Shallow clones are ideal for CI/CD builds that only need recent code, Docker image builds, or quick code reviews. They significantly reduce clone time and disk usage for large repositories. However, avoid them when you need full history for operations like:
- Semantic versioning tools (GitVersion, semantic-release)
- Changelog generation
- git blame on older commits
- Bisecting bugs across long histories

Alternative to Shallow Clones (Git 2.25+):
Consider using partial clone with blob filtering instead, which fetches all commits but delays downloading large blobs:

bash
git clone --filter=blob:none https://github.com/user/repo.git

This provides complete commit history (no unshallowing needed) while still reducing initial clone size.

Debugging Shallow Repository State:
To inspect shallow boundary commits:

bash
cat .git/shallow

Each line is a commit SHA at the shallow boundary. The number of lines indicates how many shallow boundaries exist.

Network Optimization:
For slow or unreliable connections, unshallowing can be optimized with:

bash
git config http.postBuffer 524288000  # 500 MB buffer
git config pack.windowMemory "100m"
git fetch --unshallow

This increases buffer sizes to handle large pack files more reliably.

Frequently asked questions

What does "fatal: error in object: unshallow" mean?
The "git fetch --unshallow" error occurs when Git cannot successfully convert a shallow clone into a full repository with complete history. A shallow clone is a repository that contains only a limited number of recent commits (specified by --depth), which speeds up cloning but lacks the full commit history. When you run "git fetch --unshallow", Git attempts to fetch all missing commits and objects from the remote repository to convert the shallow clone into a complete one.
How do I fix "fatal: error in object: unshallow"?
The "git fetch --unshallow" command fails when converting a shallow clone to a full repository. This typically occurs due to repository corruption, attempting to unshallow an already-complete repository, or CI/CD pipeline configuration issues.
What causes "fatal: error in object: unshallow"?
Attempting to unshallow a repository that is already a full clone (most common) Corrupted objects in the shallow repository's object database CI/CD system configured with shallow clone but tool requires full history
Is the "fatal: error in object: unshallow" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading