Git-commit-id-maven-plugin: git.commit.id.abbrev returns 8 symbols instead of default's 7 for certain commit hash

[Punkoivan]

Hello folks, thank you for the great plugin! It helps a lot with tagging our docker images.

We've faced the next issue during build with maven:
[INFO] Collected git.commit.id.abbrev with value 510b7359
We have eight symbols here, while any other commit has 7.
Really have hundreds of builds daily and facing this the very first time.

And for debug purposes we have next env variable:
[setParameter name='env.DOCKER_IMAGE' value='510b735']
which has 7 symbols (returned with SHORT_COMMIT=$(echo %build.vcs.number% | head -c 7) command)

Configuration:

            <plugin>
                <groupId>pl.project13.maven</groupId>
                <artifactId>git-commit-id-plugin</artifactId>
                <configuration>
                    <injectAllReactorProjects>true</injectAllReactorProjects>
                    <includeOnlyProperties>
                        <includeOnlyProperty>git.branch</includeOnlyProperty>
                        <includeOnlyProperty>git.commit.id</includeOnlyProperty>
                        <includeOnlyProperty>git.commit.id.abbrev</includeOnlyProperty>
                        <includeOnlyProperty>git.build.time</includeOnlyProperty>
                    </includeOnlyProperties>
                    <skipPoms>false</skipPoms>
                </configuration>
            </plugin>

Underlying projects have no configuration for the plugin.

Expected behavior

Expected 7 charachter with default comfiguration of abbrvLength, not 8.

Additional context

Plugin version: 4.0.0
Java and mvn version:

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 11.0.11-ea, vendor: Private Build
Java home: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: ANSI_X3.4-1968
OS name: "linux", version: "4.4.0-1128-aws", arch: "amd64", family: "unix"

Two hosts, one is 16.04 and another one is 18.04 Ubuntu x86_64

Maven executed via CI (teamcity and gitlab - the same result), bash.
clean install package jib:build
Not sure what was the root cause - the same configuration, the same plugin's version, hundreds build daily with two different CIs - no issues.
I assume that it could be collision or something like that with exactly that commit hash, which is 510b735913a43fbd277a5b5729e0c713ae4610e4.

Tested locally on my laptop:

➜  v2 git:(510b735913) java -version
openjdk version "15.0.2" 2021-01-19
OpenJDK Runtime Environment (build 15.0.2+7)
OpenJDK 64-Bit Server VM (build 15.0.2+7, mixed mode, sharing)
➜  v2 git:(510b735913) mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 15.0.2, vendor: N/A, runtime: /usr/local/Cellar/openjdk/15.0.2/libexec/openjdk.jdk/Contents/Home
Default locale: en_UA, platform encoding: UTF-8
OS name: "mac os x", version: "11.6", arch: "x86_64", family: "mac"

"Normal" commit:

mvn clean install package jib:build -Djib.console=plain  -Denv=prod -DskipTests=true | grep Collected
[INFO] Collected git.branch with value 5379685f3319306e3de76ebf7c8fe9b337cc3630
[INFO] Using cached git.commit.id with value 5379685f3319306e3de76ebf7c8fe9b337cc3630
[INFO] Using cached git.commit.id.abbrev with value 5379685

And with bugged commit:

mvn clean install package jib:build -Djib.console=plain  -Denv=prod -DskipTests=true | grep Collected
[INFO] Collected git.branch with value 510b735913a43fbd277a5b5729e0c713ae4610e4
[INFO] Collected git.commit.id with value 510b735913a43fbd277a5b5729e0c713ae4610e4
[INFO] Collected git.commit.id.abbrev with value 510b7359

Between those commits changes are only in few java files.

Thanks,
Ivan

[juleskers]

(I'm not affiliated with this plugin in any way, just a happy user)

This sounds like the normal git behaviour to me: writing longer abbrevs when the shorter one would be ambiguous.

Mind you, there is no 'fixed' length for abbrevs; as the repository grows, git automatically writes longer abbrevs when needed.
the abbrvLength only defines a _minimum_ length that git won't go below.

Have you checked if there is perhaps an id-collision on the 7-digit hash?
(Try git show 510b735 and see if it complains about ambiguous argument)

Example of git show on an ambiguous abbrev:

$ git show 98caafa
# error: short SHA1 98caafa is ambiguous
# hint: The candidates are:
# hint:   98caafa92 commit 2018-08-09 - Task #13930, copy of #14045 usability issues
# hint:   98caafae6 blob
# fatal: ambiguous argument '98caafa': unknown revision or path not in the working tree.
# Use '--' to separate paths from revisions, like this:
# 'git <command> [<revision>...] -- [<file>...]'

Mind you that SHA-1 hashes for git must be unique for all internal objects (trees, blobs) _and_ user-visibile objects (commits), so some git-commands may accept the 7-digit version, if they can resolve the conflict by object-type (e.g. git log only considers commits, whereas git show can/must deal with blobs/trees).

You can learn more about abbreviation logic over at Josh Stone's blog: How short can Git abbreviate?.
Specifically useful snippet from that blog: count the shortest unique abbrevs per length in your repo:

git rev-list --all --abbrev=0 --abbrev-commit | awk '{ a[length] += 1 } END { for (len in a) print len, a[len] }'
# output for linux kernel, from the blog:
# length count
#  5      1771
#  6    286066
#  7    106897
#  8      7899
#  9       494
# 10        27
# 11         3

As you can see, the larger the repo grows, the longer (some of) the abbrevs get.
Thus, you should really rework your build pipeline to handle longer abbrevs. (specifically, the head -c 7 in your SHORT_COMMIT section)

[Punkoivan]

Hello @juleskers
thank you, today I learned.

hint:   510b735913 commit 2021-11-29 
hint:   510b73520b tree

Closing the case, hope that will help more people in the future :)

Regards,
Ivan

[juleskers]

@Punkoivan Glad to have been of service! 🧡
Good luck getting your build pipeline updated!

Edit to add:
The simplest solution is probably to switch to a longer fixed size.
E.g. Linus Torvalds recommends 12 for the _current_ Linux kernel.
(and regrets ever setting the default to 'only' 7 since, in retrospect, it isn't future-proof)

If your SHA's still need to be unambiguous 10 years from now, better add some margin, e.g. 14-16.

Speaking of "helping people in the future", I've added an example git show output to my explanation above.
Good idea!