Setting the stage
git am --keep-non-patch --committer-date-is-author-date ${path-to-patch}
.The Issue
I'd expect that, regardless of where the commit was made (locally or in the Gitlab UI), the commit hash from the generated patch would match in each environment.
When applying the Git Patch, the commit hashes match in a significant majority of use-cases. However, when making a commit via the Gitlab UI, the commit hashes don't match when applied on the other system. When I run git log --format=raw
, all of the fields (tree, parent, author, committer) match perfectly on both systems, but the commit hash changes. There is no obviously discernible difference between the applied patches on either end.
What I've Tried
After force-apply pushing to a previous commit, I reapplied the patch locally and it resulted in a different hash. However, the patch would then match on the other environment.
Desired Outcome
The patches that are generated by the commits, regardless of how the commit is created, should match the commit hash.
Thoughts
Note that git am
creates a new commit, and that, in general, the new commit created will NOT have the same hash-id as the original commit it was created from.
In order for two commits to have the same hash-id, they have to be identical in every way. This includes author, committer, author-date, committer-date, the parent commit must be the same, the changes (diff) must be identical, etc. Any difference (and this includes differences that may not be visible in the log) would mean a different hash-id.
The files created by git format-patch include the author and author-date, so I would verify the committer and committer date between the original and other system. Does the Gitlab use the same committer and committer time as the new commit you created with git am
?
The real answer is: It does not matter. You do not need the hash-ids to be the same. If you want to verify if a commit is in the system, you can check the commit messages, rather than the hash-ids. If you need the same hash-ids, you'll need to track down what is different between the commits.
Also: You can avoid this problem of trying to exactly recreate commits from patches if you can adjust your environment to allow pushes/pulls between systems or perhaps transferring git bundles between systems.