Skip to main content
wit can migrate existing Git repositories while preserving your complete history. The migration process re-hashes all objects using SHA-256 and stores them in wit’s format.

Overview

When migrating from Git:
  • All commits, branches, and tags are preserved
  • Full history is maintained
  • Hash references are updated (SHA-1 to SHA-256)
  • A mapping file is created for reference

Quick Migration

For most repositories, cloning with wit handles migration automatically:

Manual Migration

For more control over the migration process:

Migration Process

The migration goes through these phases:
  1. Scanning - Discovers all Git objects
  2. Objects - Migrates blobs, trees, commits, tags
  3. Refs - Updates branches and tag references
  4. HEAD - Sets up the HEAD reference
  5. Complete - Saves mapping file

Progress Output

Hash Algorithm Options

wit supports both SHA-1 (for Git compatibility) and SHA-256:

SHA-256 (Default)

More secure and future-proof:

SHA-1 (Compatible)

Maintains original Git hashes:

Checking Migration Feasibility

Before migrating, check for potential issues:

Handling Special Cases

Shallow Clones

Shallow clones have incomplete history:
Or accept incomplete history:

Submodules

Submodules are referenced but not automatically migrated:

Git LFS

Large files stored in Git LFS need special handling:
wit’s native large file handling will be used going forward:

Pack Files

wit automatically handles Git pack files during migration:

Migration Mapping

A mapping file is created at .wit/git-migration-map:
This allows you to:
  • Look up original Git hashes
  • Verify migration completeness
  • Debug any issues

Using the Mapping

Post-Migration

After migration:

Verify the Migration

Update Remote

If you want to push to a wit server:

Keep Git Remote (Optional)

You can keep the Git remote for interoperability:

Programmatic Migration

For automation:

Rollback

If you need to go back to Git:

Troubleshooting

Missing Objects

Hash Collisions

Very rare, but if encountered:

Large Repositories

For very large repos, the migration can take time:

Best Practices

  1. Backup First - Always backup before migration
  2. Clean History - Consider cleaning up history before migrating
  3. Verify After - Always verify the migration completed correctly
  4. Test Workflows - Test your workflows in the new wit repo