Miro Kropacek Miro Kropacek - 30 days ago 7
Git Question

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

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 to make it a part of git history.

There are many ways how to achieve this but to my knowledge it always ends up with a new git tree, i.e. where all the existing commits have different IDs.

In this specific case it doesn't seem to be necessary, I'm not changing anything but the first commit's parent. Is there a way to do this?

Answer Source

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.