Cargo has different version commit hashes per platform

[abrisco]

Problem

In 1.60.0 I came across an issue where cargo version showed an unexpected difference on linux platforms in comparison to macos and windows.

Running on linux, I get:

cargo version
cargo 1.60.0 (d1fd9fe 2022-03-01)

Where as running on macos, i get:

cargo version
cargo 1.60.0 (d1fd9fe2c 2022-03-01)

Note the slight difference in the commit hash (d1fd9fe vs d1fd9fe2c). Linux is shorter than the other platforms by two characters. It would be ideal if these matched on all platforms, particularly since the full commit of each binary was not different.

Steps

1. Get a windows or macos host
2. Get a linux host or container
3. Install Cargo 1.60.0 using rustup
4. run cargo version in each environment

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.60.0 (d1fd9fe 2022-03-01)
release: 1.60.0
commit-hash: d1fd9fe2c40a1a56af9132b5c92ab963ac7ae422
commit-date: 2022-03-01
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: CentOS 8.0.0 [64-bit]

[Muscraft]

This could be an issue with #10323 potentially. If I had to guess it would be this part

let output = match Command::new("git")
    .arg("log")
    .arg("-1")
    .arg("--date=short")
    .arg("--format=%H %h %cd")
    .output()
{
    Ok(output) if output.status.success() => output,
    _ => return,
};

I don't have a spare machine to check the output on linux ATM but git log -1 --date=short --format="%H %h %cd" on mac it gives ede78751d2195a6bb0df9b9fdf3f3ced725c07ac ede78751d 2022-04-08 on the master branch.

[weihanglo]

IIRC, it might come from here?

• https://github.com/rust-lang/rust/blob/e4f5b15b8832334eca2c0bd3929eb3969f1d166d/src/bootstrap/tool.rs#L270-L272
• https://github.com/rust-lang/rust/blob/e4f5b15b8832334eca2c0bd3929eb3969f1d166d/src/bootstrap/channel.rs#L58-L60

        let short_ver_hash = output(
            Command::new("git").current_dir(dir).arg("rev-parse").arg("--short=9").arg("HEAD"),
        );

I've tested on my Linux and macOS with Git v2.35.1. Both return a 9-chars long sha with git log -1 --date=short --format="%H %h %cd".

[Muscraft]

I'm not sure if cargo uses CFG_SHORT_COMMIT_HASH anymore. It looks like it was changed to CARGO_COMMIT_SHORT_HASH in #10323 if I'm reading it correctly.

[ehuss]

I can't say why git decides to use a different length on different platforms.

Can you say more about why this is an issue? I wouldn't expect the version output to be parsable, this is really for human consumption. If you want a parsable output, I suggest to use the verbose flag which includes the full length hash.

[Muscraft]

You can specify a length with --abbrev=<length> if we do want to make the lengths the same. It would change the command to git log -1 --date=short --format="%H %h %cd" --abbrev=9.

[abrisco]

Can you say more about why this is an issue? I wouldn't expect the version output to be parsable, this is really for human consumption. If you want a parsable output, I suggest to use the verbose flag which includes the full length hash.

In rules_rust cargo --version is used to produce a unique identifier for the release of Cargo that's then used to do some work-skipping in the future if the version of Cargo hasn't changed from when something was originally generated. This issue breaks the ability to do that as linux hosts will now always think the version of Cargo has changed. Using --verbose is not desirable because it contains additional information that would not be consistent cross-platform and would cause this problem as well.

[arlosi]

This appears to be a change from the previous stable release. I'll make a PR to set the length to 9 as @Muscraft described.

On Linux I see:

$ cargo +1.59 --version
cargo 1.59.0 (49d8809dc 2022-02-10)
$ cargo +stable --version
cargo 1.60.0 (d1fd9fe 2022-03-01)