Is there a way to do git rebase with keeping the existing commit hashes?

Question

Imagine a scenario where a project has an existing git tree you\'re 100% satisfied with. Now you discover some ancient source code predating migration to git and would like

Answer 1

No, this is fundamentally impossible. A commit’s id is the hash of its combined content. That includes not only the whole tree and file content, but also the commit message, author information, and the reference to its parent.

So by changing the parent of a commit, you are changing its content and as such invalidate its previous id. Git will have to recalculate its hash in order to integrate the commit into the history. Otherwise it would reject that commit as being broken and leave your repository in a broken state.

The fact that any commit id matches the hash of its content, and that this is true for any direct or indirect parent is a core part of Git’s integrity. You cannot avoid this.

So no, you cannot do what you want without affecting commit hashes. What you maybe could do is simply add another completely unrelated branch that has no connection to your current branches. That way you wouldn’t affect your existing commits but you would also have a way to integrate that old history into the repository so it would be stored inside—not integrated but at least it’s there.