git hash in build-info version is not as stable as it could be

[jberdine]

Expected Behavior

Build_info.V1.version returns the same string when the same commit is checked out, no matter the other state of the clone.

Actual Behavior

The number of characters in the git commit hash component of Build_info.V1.version can vary.

Reproduction

I do not know a reliable way to reproduce this. The root cause of this issue is that the git describe --always --dirty command that dune invokes internally to populate the build info version depends on the state of the clone. In particular, git automatically includes more than 7 characters in order to make the hash prefix unique. This seems to take into consideration local commits, stashes, to-be-gced commits, etc. It would be more robust to explicitly specify the desired length using the --abbrev=<n> flag for some n that is uniform at least across versions of the build info library.

Specifications

• Version of dune (output of dune --version): 2.9.0
• Version of ocaml (output of ocamlc --version): 4.12.0
• Operating system (distribution and version): linux and macos

[rgrinberg]

This seems to take into consideration local commits, stashes, to-be-gced commits, etc. It would be more robust to explicitly specify the desired length using the --abbrev= flag for some n that is uniform at least across versions of the build info library.

Sounds like a good idea. Would you like to send a PR?

[jberdine]

See what you think of #4857. I used --abbrev=7 since that seems to be the default, so as not to change existing behavior in the common case.