Newer versions of git have changed the way the number of abbrev characters are computed.

The result is that MONGO_VERSION may be computed differently in the compile expansions depending on what git version is running locally.

This manifested in the embedded builders, where the build of the SDK ran on a machine that generated a 10 character abbrev string, but a consuming task ran on a machine with an older version of git that expected only 7. Since the filenames didn't match, the consuming task failed:

• Produce:
  https://evergreen.mongodb.com/task_log_raw/mongodb_mongo_master_embedded_sdk_iphoneos_embedded_sdk_s3_put_96e96c3af633f856dc0bb695c3fe0691a16459e0_19_05_07_13_40_17/0?type=T#L283

• Consume: https://evergreen.mongodb.com/task_log_raw/mongodb_mongo_master_embedded_sdk_apple_multiarch_embedded_sdk_multiarch_apple_package_96e96c3af633f856dc0bb695c3fe0691a16459e0_19_05_07_13_40_17/0?type=T#L102

There seems to be another issue as well, where even though the same machine image is used, sometimes we get a 10 digit abbrev, and sometimes 7.

On the same commit:

• 7 digit abbrev: https://evergreen.mongodb.com/task_log_raw/mongodb_mongo_master_embedded_sdk_macos_embedded_sdk_s3_put_96e96c3af633f856dc0bb695c3fe0691a16459e0_19_05_07_13_40_17/0?type=T#L261

• 10 digit abbrev: https://evergreen.mongodb.com/task_log_raw/mongodb_mongo_master_embedded_sdk_iphoneos_embedded_sdk_s3_put_96e96c3af633f856dc0bb695c3fe0691a16459e0_19_05_07_13_40_17/0?type=T#L283

So this suggests that perhaps we have a gitconfig or inconsistent git versions across the macOS fleet.

In any event, we should hardcode an abbrev size in all locations where we invoke git describe.