Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes the hash prefix returned by git-describe is 8 instead of 7 chars long #6

Open
agross opened this issue Jun 20, 2023 · 2 comments

Comments

@agross
Copy link

agross commented Jun 20, 2023

I have this strange situation where git describe --always (as invoked by git-describe from npm) returns 8 instead of 7 characters.

The issue appears to be dependent on the machine, it's not consistent but happens sometimes:

Machine 1:

agross@gh-runner-1 $ git describe --always
384f5105

agross@gh-runner-1 $ git rev-list --count HEAD
1

Machines 2:

agross@gh-runner-2 $ git describe --always
384f510

agross@gh-runner-2 $ git rev-list --count HEAD
1

I can get the has down to 7 chars by passing --abbrev-7. It seems as if git-describe (from npm) supports that flag:

const gitInfo = gitDescribeSync({ customArguments: ['--abbrev=7'] });

It would be very beneficial for this situation to hard-code the hash to 7 characters.

@TimothyJones
Copy link
Member

So, my understanding is that this is to do with ambiguity- if there is another hash with the same prefix in that repository, it will be extended to be long enough to disambiguate. I haven’t confirmed this, as I haven’t seen this situation myself.

Are the versions of git different in the two machines? Is there a difference in the way it is checked out? What happens if you do gif describe on a full local checkout that has all branches?

Is there a reason you’d like the hash to be a specific length?

@agross
Copy link
Author

agross commented Jun 21, 2023

The issue could be that the hash is ambiguous, but I do not think this is the case. The commit number reachable from HEAD is just 1 (see output of rev-list). Of course, there could be dangling commits or other unreachable objects after a history rewrite causing the short hash to be extended to 8 chars.

My CI executes absolute-version on potentially multiple servers (each a GitHub runner) during a build. One such step would be to determine a docker image tag. Another to trigger the deployment for the current HEAD commit (referring to the docker image tag) if can-i-deploy succeeds.

If the image tag is determined as 12345678-main.12345678, but the deployment is triggered for 1234567-main.1234567 this will cause the deployment to fail because the image does not exist. So all involved machines would need to agree on the hash prefix length.

A workaround that seems to work is sudo git config --system core.abbrev 7. This config setting also applies to the git-describe called by the npm package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants