Git Mirror Clone

In short: A complete copy of a Git repository including all branches, tags and the complete commit history — not just a normal checkout for working in.

In more detail: git clone --mirror <url> creates a “bare” repository (no working directory, only the .git folder). Afterwards, git push --mirror <new-url> transfers the complete history 1:1 into a new target repo. To actually continue working, you still need a normal git clone of the new repo afterwards — the mirror folder is just an intermediate step.

Our context: This is how the Bellator repo was moved completely (including history) from the old partner account to its own GitHub account, before it became “Emzett”.

In Depth

Complete procedure

The complete procedure of a repo move with a mirror clone consists of three steps:

# 1. Create a complete copy including all refs (bare repository)
git clone --mirror https://github.com/old-account/bellator.git
 
# 2. Push into the new, empty target repo (all branches, tags, history)
cd bellator.git
git push --mirror https://github.com/own-account/emzett.git
 
# 3. For actually continuing to work: normal clone of the new repo
git clone https://github.com/own-account/emzett.git

What “bare repository” means in concrete terms

A normal cloned repository has two parts: the .git folder (all history/metadata) and a working directory (the actually checked-out files you edit). A “bare” repository, as created by --mirror, consists ONLY of the .git contents, without a working directory — so there are no checked-out files at all that you could work with directly. This is intentional: a bare repository is a pure data container, meant as an intermediate station or as a target for pushes, not for direct editing. This also explains why a normal git clone of the new repo is still needed after the mirror push.

Difference from a normal clone + push

The decisive difference from a normal git clone + git push: a normal clone also fetches the full history of the currently checked-out branch, but NOT automatically all other branches/tags, and a normal push only transfers the current branch, not the entire web of references. When moving a repo (unlike in daily work), however, you really do want to take everything along 1:1, including branches you may never have checked out yourself — such as old feature branches or tags of past releases that remain relevant for the complete history.

What does NOT come along

An important point that’s easily overlooked when moving repos: a mirror clone transfers the complete Git history, but NOT platform-specific metadata such as GitHub issues, pull requests, wiki pages, releases (as GitHub objects, not as Git tags) or repository settings (branch protection rules, webhooks, configured secrets). These things live outside the pure Git object model in GitHub’s own database and have to be migrated or set up again separately in a real platform move.

Authentication during the mirror push

Since a mirror push potentially transfers a very large number of refs at once, it’s particularly prone to authentication problems with large repositories — an expired token or a misconfigured SSH connection often only causes an error in the middle of the transfer, which can leave the target repo in an incomplete intermediate state. It’s therefore advisable to compare the number of branches/tags in the target repo with the original after a mirror push, before deleting or archiving the old repository.

See also: SSH key (Git authentication), Git