Hi, I apparently managed to break the cryptographic merkle hash tree property of git using git-filter-repo --force on a non-bare repo. Is that expected?
Before vs after its use, I see the same commit SHA, but with two different parents, which shouldn't be possible in git.
git log --graph --oneline before (which I still have in a clone of the repo on another machine_:
* 40015ad01 commit2
* 22bfa27af commit1
And after:
* 40015ad01 (replaced) commit2 <- same hash
* 73470af38 commit1 <- but different parent
git fsck outputs some errors such as:
error: Could not read 002300c0e7abaa6712118a75858df142fc4acbde
failed to parse commit 002300c0e7abaa6712118a75858df142fc4acbde from object database for commit-graph
error: Could not read 0094a58e9fe88ab27692428a11ddabaed94eca42
failed to parse commit 0094a58e9fe88ab27692428a11ddabaed94eca42 from object database for commit-graph
Is it expected that --force can cause that?
If yes, it might be good to point that out in the man page, recommending to use git fsck, because I didn't notice that all my historical git commits in this checkout are cryptographically wrong for ~2 weeks after my rewrite succeeded.
I used git-filter-repo for a basic textual replacement.
Hi, I apparently managed to break the cryptographic merkle hash tree property of
gitusinggit-filter-repo --forceon a non-bare repo. Is that expected?Before vs after its use, I see the same commit SHA, but with two different parents, which shouldn't be possible in git.
git log --graph --onelinebefore (which I still have in a clone of the repo on another machine_:And after:
git fsckoutputs some errors such as:Is it expected that
--forcecan cause that?If yes, it might be good to point that out in the man page, recommending to use
git fsck, because I didn't notice that all my historical git commits in this checkout are cryptographically wrong for ~2 weeks after my rewrite succeeded.I used
git-filter-repofor a basic textual replacement.