I have encountered a situation where two different Git commits with distinct SHA-1 hashes represent the same changeset. Is there a way to conclusively identify that these commits indeed contain the same changes, even though they have different commit hashes?
Here's the context:
Commit 1: SHA-1 Hash abcdef1234567890 Commit Message: "Fix issue #123" Author: xyz Author Date: [Insert Date] Changes: [List of changes]
Commit 2: SHA-1 Hash xyz7890abc123456 Commit Message: "Fix issue #123" Author: xyz Author Date: [Insert Date] Changes: [List of changes]
Both of these commits have the same commit message and address the same issue. The content appears similar, but the SHA-1 hashes are different.
This scenario arise whenever we perform rebase with any branch. Whenever we perform a rebase then parent commit will change, which leads to change of a SHA. I'm storing commits across the branches, but due to frequent rebase operation commit SHA gets changed, and storing duplicate commits with same changeset.
I want to determine whether these commits represent the same changeset or if there are subtle differences. Is there a Git command or a specific technique I can use to say that this commit is identical to another commit and already stored?
Any advice or guidance on this would be greatly appreciated.
Tried Git diff command to return only file names for two commits.
If you have the commit hashes, you can use range-diff:
As the name says, you can use it to check the difference of the changes between two range of commits.
Check the documentation for more information: https://git-scm.com/docs/git-range-diff
PS: range-diff was introduced in git 2.31, some older operating systems (e.g. Ubuntu 20.04, Debian Bullseye) are't shipped with it.