How to fix fatal: shallow update not allowed in Git

GitINTERMEDIATEMEDIUM

This error occurs when pushing to a remote repository from a shallow clone, or when the remote itself is shallow and rejects updates. The fix involves unshallowing your local repository or reconfiguring the remote to accept shallow updates.

What this error means

The "fatal: shallow update not allowed" error indicates that Git is rejecting an operation because it involves a shallow repository that lacks sufficient commit history. A shallow clone is created using `git clone --depth N`, which downloads only the most recent N commits instead of the full history. While this speeds up cloning, it creates limitations: Git needs ancestor commits to properly merge histories, verify refs, and perform certain operations like rebasing across the shallow boundary. This error typically appears in two scenarios: 1. **Pushing from a shallow clone to a new remote**: Your local shallow clone doesn't have enough history to establish a proper connection with the destination repository. 2. **Pushing to a shallow remote**: The receiving repository is itself shallow (uncommon but can happen with improperly configured mirrors), and its configuration blocks updates that would require history it doesn't have. Since Git 1.9+, pushing from shallow clones is supported, but only when the remote already shares the commits in your history up to your shallow boundary.

How to fix "fatal: shallow update not allowed"

1Unshallow your local repository

The most reliable fix is to convert your shallow clone to a full clone by fetching the complete history:

bash

# Fetch complete history from the original remote
git fetch --unshallow origin

# Verify the repository is no longer shallow
git rev-parse --is-shallow-repository
# Should output: false

After unshallowing, retry your push operation. This downloads all missing commits, so it may take time for large repositories.

2Re-add the original remote for unshallowing

If you've changed your remote URL and no longer have access to the original, you'll need to add it back temporarily:

bash

# Check your current remotes
git remote -v

# Add the original remote (if different from current)
git remote add original https://github.com/original-owner/repo.git

# Unshallow from the original remote
git fetch --unshallow original

# Remove the temporary remote
git remote remove original

# Now push to your new remote
git push -u origin main

3Deepen the clone to include required commits

If you only need to push specific commits and don't want the full history, you can selectively deepen your clone:

bash

# Fetch more history (e.g., 100 commits)
git fetch --depth=100 origin main

# Or fetch enough to include a specific commit
git fetch --shallow-since="2024-01-01" origin main

# Check how much history you have
git log --oneline | wc -l

This is faster than a full unshallow but may not work if the remote requires commits older than what you fetch.

4Configure remote to allow shallow updates (if you control it)

If you have admin access to the receiving repository and understand the implications, you can configure it to accept shallow updates:

bash

# On the remote server (SSH into it or use git config)
cd /path/to/repo.git
git config receive.shallowUpdate true

Warning: This is generally not recommended for shared repositories. It can lead to incomplete history on the remote, causing issues for other users who clone from it.

5Create a fresh clone with full history

If other methods fail, the cleanest solution is to re-clone without the shallow option:

bash

# Backup any local changes
git stash
git format-patch origin/main --stdout > my-changes.patch

# Clone fresh with full history
cd ..
rm -rf old-repo
git clone https://github.com/user/repo.git new-repo
cd new-repo

# Apply your changes if needed
git am < ../my-changes.patch

6Use partial clone instead of shallow clone

For future clones, consider using partial clone instead of shallow clone. It downloads all commit metadata but skips large blobs until needed:

bash

# Partial clone - fetches commit history but not all blobs
git clone --filter=blob:none https://github.com/user/repo.git

# This avoids shallow-specific errors while still saving bandwidth

Partial clones maintain full commit history, so operations like push, rebase, and merge work normally.

Advanced notes

### How Shallow Clones Work

When you run git clone --depth N, Git:
1. Downloads only the last N commits from each branch tip
2. Creates a .git/shallow file listing the "boundary" commits
3. Treats these boundary commits as if they have no parents

The .git/shallow file contains commit hashes that Git pretends are root commits. This works for viewing code but breaks operations that need to traverse history beyond the boundary.

### Why Git 1.9+ Still Has This Error

While Git 1.9 added support for pushing from shallow clones, it only works when:
- The remote already has the commits in your local history
- Your shallow boundary commits exist on the remote
- You're pushing new commits that descend from the remote's existing refs

When pushing to an unrelated repository (fork, new empty repo, or changed remote), the remote doesn't recognize your boundary commits, so Git rejects the push.

### CI/CD Best Practices

In CI/CD pipelines, shallow clones are common for speed. To avoid this error:

yaml

# GitHub Actions - use full clone when pushing is needed
- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Full history

# GitLab CI
variables:
  GIT_DEPTH: 0  # Disable shallow cloning

### Server-Side Configuration

Some Git servers have additional configurations:

bash

# Check server config (if you have access)
git config --get receive.shallowUpdate
git config --get receive.denyDeletes
git config --get receive.denyNonFastForwards

GitHub, GitLab, and Bitbucket handle shallow updates automatically for most operations, but self-hosted Git servers may need manual configuration.

### Alternative: Interactive Rebase

If you only need a few commits from a shallow clone, you can squash them into new commits that don't reference the shallow boundary:

bash

# Create a new orphan branch and cherry-pick your commits
git checkout --orphan fresh-start
git commit -m "Initial commit with squashed history"
git push -u newremote fresh-start:main

This discards history intentionally but creates a clean starting point.

How to fix fatal: shallow update not allowed in Git

What this error means

Typical symptoms

Common causes

How to fix "fatal: shallow update not allowed"

Advanced notes

Related errors

Official resources & further reading