Github - There isn’t anything to compare

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! :slight_smile:

3 Likes

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.

5 Likes

Hi @kinetiksoft, thanks for bumping this topic!
I believe Simon’s right. Thank you for this amazing explanation! :slightly_smiling_face: I never thought this might be the problem.

Yes the problem is solved for me after a few commits.

2 Likes

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:

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
5 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.