🌿
Git Error
Git Error: refusing to merge unrelated histories
Git detected two branches with no common commit ancestor and, by default, refuses to merge them without explicit confirmation.
What This Error Means
Since Git 2.9, `git pull` or `git merge` refuses by default to merge two branches that share no common commit history — this is a safety check against accidentally merging two genuinely unrelated repositories or histories together.
Why It Occurs
Commonly happens when initializing a new local repository and then pulling from a remote that already has its own separate history (e.g. a repo created with a README on GitHub, then cloned/initialized separately locally before the first pull), or when re-initializing a repository's git history.
Symptoms
- ⚠ Appears specifically on `git pull` or `git merge`, not on `git clone`
- ⚠ The two branches genuinely do have unrelated commit histories, confirmed by `git log` showing no shared commits
Common Causes
- • A local repository was initialized independently (`git init`) instead of cloned, then a remote was added and pulled from
- • A repository's .git history was deleted and reinitialized
- • Genuinely merging two different projects' histories together intentionally
How to Fix It
- If this is expected (e.g. combining an independently-initialized local repo with a remote that already has commits), allow it explicitly: `git pull origin main --allow-unrelated-histories`
- If this is unexpected, verify you're pulling from the correct remote and branch — an unrelated-histories error on a repo that should share history usually means a mistake in which remote/branch you're working with
- After merging with --allow-unrelated-histories, carefully review the merge for unexpected file conflicts, since Git had no common ancestor to base a clean 3-way merge on
| Command | Purpose |
|---|---|
| git pull origin main --allow-unrelated-histories | Force the merge despite no common history, when this is genuinely intended |
Advertisement
Verification
- ✓ Confirm the merge completed and `git log` shows both histories combined as expected
- ✓ Review the actual file contents post-merge for any unexpected overwrites
Prevention
- → Always `git clone` a remote repository rather than `git init` locally and adding a remote afterward, when the remote already has commits