Desk Clarity

Everyday document & browser help

Git unrelated histories after an initial README: choose one starting history

By ON Lab · Sources checked November 8, 2026

A local git init followed by a local commit and a separately initialized remote README create two independent histories. Adding the remote URL does not create a shared ancestor. If you have not yet started local history, clone the initialized remote and add your project files there. If both histories already matter, preserve them and deliberately choose how to integrate them instead of routinely bypassing the unrelated-history check.

A historical reader repeatedly hit this error after creating a local repository and a remote repository with an initial README. They asked whether starting with an empty remote or cloning the initialized remote was the right approach. We checked current Git documentation and reproduced both independent roots and a clone-and-import path using local disposable repositories.

Inspect the graph before changing it

git status --short
git log --oneline --graph --all --decorate
git merge-base HEAD origin/main

Use your actual remote-tracking branch name rather than assuming main. These commands inspect the locally available state. A remote-tracking reference reflects the last fetched state, not a live read of the hosting site. Review the configured remote and fetch from the intended repository when you need an up-to-date comparison.

For our two independent roots, merge-base returned no common ancestor and exited with status 1. The ordinary merge then refused unrelated histories. That combination differs from a failed lookup of a nonexistent branch or from an authentication failure; read the actual error instead of treating every nonzero command as the same condition.

Choose the starting workflow before two roots exist

Starting situationSuitable workflowHistory consequence
Initialized remote; local files have no history to preserveClone the remote, then import reviewed filesNew commits descend from the remote's initial commit
Existing local history; remote is intentionally emptyConnect the intended empty remote and publish through the normal reviewed workflowThe local history becomes the starting history
Both sides already contain valuable independent commitsPreserve both and review an explicit integration strategyA content import and a history merge are different choices

The empty-remote path means genuinely no initialized remote commit, not “a remote with only a README.” This guide does not create or push to a hosted repository. Verify the hosting setup and your publication authority before any real push.

What our reproduction showed

We made one repository with a README commit and another with an app.txt commit. Their roots were independent. After adding the first as a local-path remote and fetching, an ordinary merge refused. An explicit merge with allow-unrelated-histories created a commit with both prior roots as its parents and retained both files.

In a second path, we cloned the README repository into a new folder, copied only the reviewed app file, and committed it. A merge-base ancestry check confirmed that the README commit was an ancestor of the new import commit. There was one continuing history for this import, so no unrelated-history override was needed.

These tiny fixtures had different filenames and no conflicts. A real project may have competing README, license, configuration or source files. Successful integration in our fixture does not establish the right contents or absence of conflicts in your repository.

Import content without copying repository internals

If clone-and-import fits your situation, preserve the original folder first and work in a separate new clone. Review which source files should be imported. Do not copy the old .git directory over the clone: that directory carries repository identity, history and configuration, not just project content.

Compare files that already exist in the clone before replacing them. Review the status and full staged diff, exclude local secrets and generated material according to the project, and run relevant checks before committing. The import preserves the chosen file contents as a new commit; it does not preserve the old local commit sequence.

If your local commits, branches, tags or audit history matter, a file-only import may be the wrong choice. Do not delete the original repository because the new clone can run the application. Decide what history must remain available before choosing that tradeoff.

When an explicit unrelated-history merge is intentional

Git documents allow-unrelated-histories for intentionally combining independently started projects. It is an override of a deliberate check. Test it on an isolated integration branch after confirming the two repositories are the ones you intend to combine.

git switch -c review-independent-import
git merge --allow-unrelated-histories origin/main
git status --short
git log --oneline --graph --all --decorate

The command can require conflict resolution. Read the final staged content and commit before sharing it. An active merge can be aborted through the documented merge workflow, but do not assume that recovers unrelated uncommitted work without prior preservation. Starting clean keeps the state easier to assess.

A force push is not a way to create the missing ancestry. It changes what a remote reference points to and can discard someone else's reachable branch history from that reference. This starting-history problem can be understood and resolved without making a force push the routine first step.

Completion checks

  1. Confirm whether each side has an initial commit and which history needs preservation.
  2. Inspect the actual remote-tracking branch and common-ancestor result.
  3. Choose content import or intentional history integration explicitly.
  4. Review conflicting files, the full staged patch and the resulting graph.
  5. Keep the original repository until the intended contents and history are verified.

Checked November 8, 2026 with local disposable repositories. Both-root merge and clone-plus-content-import were tested. No hosting login, network push, original project or overlapping-file conflict was exercised.

Sources