Is --preserve-commit-hashes working ok?

[digerzo]

Hello everyone,

I have a use case in where a fork from a public repo needs to be pushed into a private repo, but with a certain string inside the commit message, lets say, APRED101. I've managed to re write the git history using filter-repo as:

$ git-filter-repo --preserve-commit-hashes --source <path to local-public repo> --commit-callback ../commit-message-callback.py --refs HEAD

Inside file commit-message-callback.py I've put:

msg = commit.message.decode("utf-8")
newmsg = "APRED101: " + msg
commit.message = newmsg.encode("utf-8")

In this use case, I need to also maintain the history of the original public repo, so in the future I can pull updates. I was wondering to use --preserve-commit-hashes to actually keep the original commit sha1 and thus, accomplish this requirement. But this is not working as I expect, since the outcome history has all the messages with new messages, but with different commit sha1.

Is this the expected use to --preserve-commit-hashes?

Regards,
Agustin

[newren]

This isn't what you wanted to hear, but you've invented a meaning for --preserve-commit-hashes that is divorced from its documentation and intent. Further, what you want is impossible; see https://github.com/newren/git-filter-repo/blob/main/Documentation/FAQ.md#why-did-git-filter-repo-rewrite-commit-hashes and https://github.com/newren/git-filter-repo/blob/main/Documentation/FAQ.md#Filtering-history-but-magically-keeping-the-same-commit-IDs.

The --preserve-commit-hashes option tells git-filter-repo to not rewrite commit messages to update references to old commit hashes. By default, when git-filter-repo rewrites history (creating new commit hashes), it scans commit messages for references to commit IDs (or their abbreviations) and updates those references to point at the new hashes, so that cross-references in commit messages remain valid after rewriting.

When you use --preserve-commit-hashes, this automatic updating is disabled:

• Commit messages will be left exactly as they were, even if they contain references to old commit hashes that no longer exist or are now stale.
• This is useful for workflows where you do not care if commit-message references become stale, or where you specifically want to preserve the original commit messages as-is.

It does not have anything to do with avoiding changes to commit hashes themselves; it is strictly about whether commit messages should be automatically updated to track rewritten commit IDs.