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.

Answer 2

I agree that it is almost impossible, but it would be technically possible.

You should create a commit after the old one so that after the rebase, your new commit ends up with the same hash

Of course this is quite hard to do and is not guaranteed that exists another hash, different from the current parent that satisfies this condition

Answer 3

yes, If you want to save the existing commit hashes: Just create a new_branch before you rebase the current branch. So that when you checkout to new_branch all the history will be seen.