Question & Answer

Question: Are git commit id:s truncated in CET Developer?
You may have noticed that often the commit id you see in CET Developer is shorter (or longer) than the one you see for the same commit on GitLab.

Answer: GitLab doesn't use the same standard as the git client.
GitLab seems to always represent the short commit id using 8 characters, while CET Developer uses git's built-in function for showing the short commit id, and the number of characters it will use depends on the size of the project. It will by default use 7 characters, but as the project grows larger it will use more characters.

Background

Here's a short background about git commit hashes and short commit hashes:

A commit in git always has a hash that contains 40 characters. But to make the id:s easier to handle it also supports using a short version of the id. The short commit id can actually be any number of characters as long as it's unique for a commit within the same repo.

For example, we can use the initial commit for the version10.0-branch which will currently display the following 10 character commit id in CET Developer (and also in git bash): 522e2ca801

By using the following command you can see the full commit hash for it:

>git rev-parse 522e2ca801
522e2ca8010c77fb76f1766dc72a0de81524cd6d

You can also use the parameter --short to see the short commit id as git represents it:

>git rev-parse --short 522e2ca801
522e2ca801

But when you go to GitLab you will see that the commit id for the same commit is displayed as:

522e2ca8

In smaller repositories, git client and CET Developer will use 7 characters for representing the short commit id while GitLab still uses 8 characters, which might give the impression that the commit id:s in CET Developer has been truncated.

Actually, you can use an even smaller portion of the full commit hash to represent the commit as long as it's unique.

For example, currently, this commit hash is still unique within the repo even if it just has 6 characters:

>git rev-parse --short 522e2c
522e2ca801

But if you try to shave it down to 5 characters it will give you an error message that the short hash is ambiguous:

>git rev-parse --short 522e2
error: short SHA1 522e2 is ambiguous
hint: The candidates are:
hint:   522e27edca commit 2019-07-05 - Merge branch 'version10.0' into 'version10.0cat'
hint:   522e2ca801 commit 2018-09-27 - Initial commit for version10.0 branch
hint:   522e26502f blob
hint:   522e2b12da blob
fatal: Needed a single revision

Conclusion

The conclusion is that git short commit hashes have variable lengths.

The only requirement for a git short commit hash is that it's unique within that repository, the git client will use variable length (default: 7) while GitLab seems to always use 8 characters.

Final Note

The final note is a warning when storing short commit id:s for future use:

Since the length required for the short commit hash in order to be unique will be longer as the project grows larger, a short commit hash that is valid for representing a commit today might not be that in the future!

So if you're referencing git commits outside git itself (for example included in builds that you ship or in issue handling systems), it's recommended that you either use the full commit or at least a large enough portion of it to guarantee it will stay unique as the project grows.