GitHub Community
Why does comparisons sometime yield different results? #198543
-
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
|
Thank you very much for this explanation! I had thought that the compare function would compare only the latest commit to each branch. I didn’t realize that it compares the ancestry of commits. That does make a difference.
Rod
From: Madireddy Meena Mahanth Harinadh ***@***.***>
Sent: Friday, June 12, 2026 11:13 PM
To: community/community ***@***.***>
Cc: Falanga, Rod, DOH ***@***.***>; Author ***@***.***>
Subject: [EXTERNAL] Re: [community/community] Why does comparisons sometime yield different results? (Discussion #198543)
CAUTION: This email originated outside of our organization. Exercise caution prior to clicking on links or opening attachments.
GitHub's compare view is not always symmetric because the order of the branches matters.
When you use:
branch1...branch2
GitHub treats one branch as the base and the other as the comparison branch. It determines what commits are reachable from one branch but not the other, using their common ancestor (merge base).
If both branches ultimately point to the same commit, GitHub may report that they are identical regardless of order. However, if the branches have different commit histories (for example due to rebases, cherry-picks, or different merge paths) while producing the same file contents, reversing the comparison can yield different results.
In other words, GitHub is comparing commit ancestry, not just the final file state.
A common example is when:
branch2 contains all commits from branch1 plus additional commits → comparing branch1...branch2 shows those extra commits.
Reversing the comparison changes which branch is considered the source of the changes, so the result may differ.
If you're seeing a case where one direction says the branches are identical and the other does not, it would be interesting to see the branch graph (git log --graph --oneline --all) because rebases or cherry-picks are often involved.
-
Reply to this email directly, view it on GitHub<#198543?email_source=notifications&email_token=A6LUKRM7RSBCYZAIIK5QZET47TPF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHA3DQMBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17286804>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A6LUKRL5MFVPE4BNIMFAPPD47TPF5AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMBSGI4DQNBUUF3AE>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/A6LUKRM74VNRXHMXTKCOOZT47TPF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHA3DQMBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android<https://github.com/notifications/mobile/android/A6LUKRJE5U7X4H6XYXXPDV347TPF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHA3DQMBUUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today!
You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
|
GitHub’s compare view is not always symmetric because the order of the branches matters. It compares commit ancestry using the common ancestor (merge base), not just the latest commit or final file contents. So reversing branch1...branch2 can produce different results, especially when rebases, cherry-picks, or different merge paths are involved. |
Beta Was this translation helpful? Give feedback.
-
|
A simple example that helped me understand this is: Suppose A → B → C and A → B → C → D → E Comparing:
shows commits D and E because they exist on Reversing it:
may show no unique commits because Things become even more interesting after rebases or cherry-picks. Two branches can contain effectively the same code while having different commit histories, so GitHub's compare view may still report differences because it is comparing commit ancestry rather than only the final file contents. That's why "same code" and "same history" are not always the same thing from Git's perspective. |
Beta Was this translation helpful? Give feedback.
-
|
This is very helpful, thank you! |
Beta Was this translation helpful? Give feedback.
This comment was marked as low quality.
This comment was marked as low quality.
-
Beta Was this translation helpful? Give feedback.
GitHub’s compare view is not always symmetric because the order of the branches matters. It compares commit ancestry using the common ancestor (merge base), not just the latest commit or final file contents. So reversing branch1...branch2 can produce different results, especially when rebases, cherry-picks, or different merge paths are involved.