Introduction

With plain Git, correcting old author metadata usually means rewriting history. With git svn, there is an extra complication: imported Git commits are tied to Subversion revision metadata, so rewriting them can break the mapping that git svn relies on for future fetch, rebase, and dcommit operations.

First Decide What Kind of Repository You Have

The safe answer depends on one question:

1. Is this still an active git svn bridge to Subversion?
2. Or is it now just an ordinary Git repository that happened to originate from SVN?

If SVN interoperability still matters, be conservative. If it no longer matters, you can use ordinary Git history rewriting tools.

Active git svn Repository: Prefer Rebuilding

If the repository still uses git svn, the safest fix is usually:

• correct the authors mapping file
• recreate the Git mirror from SVN

Example authors file:

jdoe = Jane Doe <[email protected]>
asmith = Alex Smith <[email protected]>

Then build the repository with the corrected mapping:

1git svn clone \
2  --authors-file=authors.txt \
3  https://svn.example.com/repo/project \
4  project-git

This preserves a clean git svn mapping from imported Git commits back to SVN revisions.

Why Rewriting Is Risky with git svn

git svn stores metadata that links Git commits to Subversion revision numbers. If you rewrite imported commits:

• commit IDs change
• the metadata chain can stop matching cleanly
• later git svn operations may become unreliable

That is why fixing the author mapping and rebuilding is usually better than retroactively editing imported commits in place.

If the Repository Is Now Plain Git

If you no longer use git svn operationally and only care about the Git repository, then rewriting author metadata is reasonable. In that case, the modern tool is git filter-repo.

A mailmap rewrite is compact:

git filter-repo --mailmap my-mailmap.txt

Example mailmap:

Jane Doe <[email protected]> <[email protected]>
Alex Smith <[email protected]> <[email protected]>

This updates author and committer identity across rewritten Git history.

What About Interactive Rebase

Interactive rebase is fine for a few recent commits on a pure Git branch that you control. It is not the right tool for mass correction of imported git svn history.

Use rebase when:

• only a handful of recent commits are wrong
• the branch is local or tightly controlled
• there is no git svn metadata concern

Use a rebuild or full rewrite for large imported histories.

Collaboration Implications

Any history rewrite changes commit IDs. That means:

• collaborators must resynchronize
• force-push may be required
• old branch references become stale

In a git svn bridge, those problems are even more sensitive because your Git history is not just shared with Git users. It also has a conceptual mapping back to SVN revisions.

Practical Decision Rule

Use this rule of thumb:

• still using git svn: fix authors-file and reclone
• no longer using git svn: rewrite with git filter-repo or another Git-native tool

That is the operationally safe answer in most teams.

Common Pitfalls

The biggest mistake is treating a git svn mirror like an ordinary Git repo and rewriting imported history without considering SVN metadata.

Another mistake is using interactive rebase for a large authorship correction job. Rebase is for recent commit editing, not for broad imported history cleanup.

People also forget that fixing the Git side does not rewrite the canonical Subversion repository. If SVN remains the source of truth, rebuilding from SVN with the right authors mapping is often the cleanest fix.

Finally, do not rewrite history without a backup or a fresh clone. That is especially important when imported revision mapping is involved.

Summary

• With active git svn usage, retroactive author correction is usually best handled by fixing the authors mapping and rebuilding the clone.
• Rewriting imported history can break the git svn revision mapping.
• If the repository is now plain Git, git filter-repo is the modern way to rewrite author metadata.
• Interactive rebase is fine for a few recent pure-Git commits, not for broad imported histories.
• Decide first whether SVN interoperability still matters, then choose the repair strategy.