How to fix fatal: missing objects during shallow fetch in Git

The most reliable fix is to remove the shallow restriction entirely by fetching all missing history:

git fetch --unshallow

This downloads all commits from the remote, converting your repository to a complete clone. After this operation, the .git/shallow file is removed and you have full access to the repository history.

Note: This can be slow for large repositories as it downloads the entire commit history.

If a full unshallow is too time-consuming, you can incrementally deepen the history:

# Increase depth by 100 commits
git fetch --depth=100

# Increase depth by 500 commits
git fetch --depth=500

# Continue until the error resolves, then optionally unshallow
git fetch --unshallow

This approach downloads history in manageable chunks, which can help identify how much history you actually need. Some CI systems benefit from this approach as it balances speed with functionality.

If you're fetching from another shallow repository or encountering issues with shallow boundaries, use the --update-shallow flag:

git fetch --update-shallow origin main

By default, Git refuses refs that would require updating the .git/shallow file. The --update-shallow flag allows Git to accept such refs and update the shallow boundaries accordingly.

You can also fetch all refs with this flag:

git fetch --update-shallow --update-head-ok origin '+refs/heads/*:refs/heads/*'

Shallow clones often use --single-branch by default, which limits fetching to one branch. If you need other branches, edit your fetch refspec:

# Check current fetch configuration
git config --get remote.origin.fetch

If it shows something like +refs/heads/main:refs/remotes/origin/main, change it to fetch all branches:

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

# Now fetch with unshallow
git fetch --unshallow

Alternatively, manually edit .git/config and change the [remote "origin"] section's fetch line.

If the shallow clone is severely corrupted or the above steps don't work, a fresh clone may be faster:

# Backup any local changes
git stash
git diff > ~/my-changes.patch

# Move the old repository
cd ..
mv myrepo myrepo-old

# Clone fresh (full clone)
git clone https://github.com/user/repo.git myrepo

# Or shallow clone with more depth
git clone --depth 100 https://github.com/user/repo.git myrepo

# Apply your changes back
cd myrepo
git apply ~/my-changes.patch

For CI/CD pipelines, configure the clone depth appropriately based on your needs:

GitHub Actions:

- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Full clone (recommended for version detection)
    # Or use a specific depth:
    # fetch-depth: 100

GitLab CI:

variables:
  GIT_DEPTH: 0  # Full clone
  # Or:
  # GIT_DEPTH: 100  # Last 100 commits

Azure DevOps:

steps:
- checkout: self
  fetchDepth: 0  # Full clone

Using fetch-depth: 0 prevents most shallow-related issues at the cost of longer clone times.