Hello,
I am on 940eb28e31 . And now if i click the commits to view it on Github.
After click it won’t find anything… Is Discourse change branch or what am i missing? I always check the commits before upgrade.
Thank you! 
סיכום מבוסס בינה מלאכותית
Users reported an issue where clicking on a commit hash in Discourse to view it on GitHub resulted in a “not found” error. Don first highlighted the problem, noting that the commit hash was not resolving correctly. Simon_Manning identified that the issue likely stemmed from commit hash ambiguity—GitHub couldn’t determine which commit to display when multiple commits shared the same short hash. He explained that git rev-parse --short generates 7-character hashes, which can lead to collisions, especially with orphaned commits. Don confirmed the issue resolved after additional commits were made, reducing the chance of collision. david shared that they had identified 7-character hash collisions on the main branch and submitted a PR to fix the issue by using full commit hashes in GitHub links, preventing future ambiguity.
Hi,
We’re experiencing the same issue. Did you have a chance to solve it?
Using the compare from the OP (940eb28e…fc61a7c0) I see the same result. Adding one more character of the second commit hash (940eb28e…fc61a7c0d) I get the correct comparison.
My suspicion is that this is caused by commit hash ambiguity, i.e. there are two commits that both start with fc61a7c0 so it doesn’t know which one to use. I don’t see it in the commit history but it could be orphaned.
It looks like docker_manager uses git rev-parse --short to get the hashes for that URL. In theory that will produce unique hashes starting at 7 (by default) characters long and increasing in length as necessary to guarantee uniqueness. Orphaned commits are ignored when pulling though so what git believes to be unique on a Discourse instance might not be unique on GitHub.
This will be quite rare though and there have been commits since your post so the problem has probably already gone away if you check for updates again.
Hi @kinetiksoft, thanks for bumping this topic!
I believe Simon’s right. Thank you for this amazing explanation! 
I never thought this might be the problem.
Yes the problem is solved for me after a few commits.
Very interesting - thanks for figuring it out @Simon_Manning
I’ve made a PR which will update docker_manager so that it uses the full commit hash in GitHub links:
https://github.com/discourse/docker_manager/pull/128
Doesn’t look like we have any 8-character collisions on the main branch yet. But we do have a handful of 7-character collisions:
❯ git rev-list --all | cut -c1-7 | sort | uniq -d
27c793a
3483c7b
45a166b
96aca6d
c2e58b6
f73ed45