History preservation should be chosen repository by repository, with explicit decisions for commits, tags, active branches, authorship, and source references before any import changes the canonical record.
Define what preservation means
Teams use the word history to mean several different things. One buyer may need line-level blame after paths move, another may need release tags and authorship, and a third may only need durable links to archived source repositories. Write the required queries first. Examples include tracing a production line to its original commit, reconstructing a release, or proving where a licensed component entered the codebase.
Inventory default branches, active feature branches, tags, submodules, large-file storage, generated artifacts, and identity mappings. Decide which repositories remain read-only after migration and which may be retired. This record constrains the migration method and gives reviewers a way to detect missing history before the canonical branch becomes the source of active work.
Choose an import method per source
Git subtree merges can place another repository under a directory while retaining its commits, and GitHub documents the method and its operational cautions. Filtered imports can rewrite paths more cleanly but also rewrite commit identities. A plain snapshot is simpler when the old repository will remain permanently available. Each choice trades continuity, repository size, and operational complexity.
Perform imports on temporary branches and record the exact commands, source commit IDs, destination paths, and identity changes. Tags may collide even when file paths do not, and branch names can conceal active work. A migration ledger should state which references were preserved, renamed, archived, or rejected, along with the buyer decision that authorized each exception.
Test history as a user would query it
Validation should exercise the actual historical questions. Run blame on moved files, locate known commits, inspect merged authorship, resolve representative tags, and compare selected releases with their source repositories. Build and test behavior must also remain intact because a perfect commit graph does not compensate for a canonical repository that cannot reproduce the product.
The buyer owns the legal and operational decision about what history must remain available. Reality Contact, LLC can execute the approved import and produce a traceable ledger, but it does not decide source rights or erase source repositories. Original repositories should remain protected until the buyer accepts both functional and historical checks.
Where the service stops
Reality Contact, LLC performs the scoped repository conversion and prepares technical evidence, but the buyer owns source rights, licensing decisions, repository access, product behavior, deployment authority, and final acceptance of the canonical branch. The buyer approves the package and history map, reviews the acceptance record, designates the canonical repository, and moves active development and deployment ownership to it. This is technical implementation and documentation based on buyer-authorized repositories, and it does not replace legal, security, licensing, compliance, or professional advice. The buyer controls source rights, credentials, branch protection, history policy, acceptance cases, deployment authority, and every production release.
Sources: GitHub guide to Git subtree merges.