Add Git information to cargo-gpu's --version CLI subcommand

[Steveplays28]

Old:

$ cargo-gpu --version
cargo-gpu 0.10.0-alpha.1

New:

$ cargo-gpu --version
cargo-gpu 0.10.0-alpha.1 (2e5047eb4b; 2026-06-28)

I left the short version subcommand (-V) unchanged.

[nazar-pc]

It is just my opinion, but it seems really wasteful to add such a massive dependency tree for such a tiny feature.

You essentially added more than 1000 lines of dependencies just to obtain VERGEN_GIT_COMMIT_DATE environment variable, which doesn't make sense to me. Everything else was already there.

Adding commit hash is a single line change instead of current +1346 -80, adding date is a bit more than that, but still less than what this PR does.

[Steveplays28]

@nazar-pc well okay, fair.
I'll keep the Git CLI invocation that was there before

[Steveplays28]

I added a helper function for invoking Git, added cargo:rerun-if-changed lines and got the date through the Git CLI. Thanks for checking the PR, Nazar.

My bad for not doing it in this simple way in the first place, I agree that this is better. Less time needed to compile and less code to maintain

[nazar-pc]

This looks much better, thanks 🙂

[nazar-pc]

Are you sure these rerun-if-changed are actually needed?
If installed from git repository, the revision will have to change, and the whole crate will be recompiled anyway.

I'm not sure what is the situation where these are actually necessary.

[Steveplays28]

from what I read on StackOverflow it is but I haven't tested without those rerun-if-changed lines 😅

[Steveplays28]

I just tested it, if I make a commit without those rerun-if-changed lines, then re-compile with e.g. cargo run -p cargo-gpu -- --version, COMMIT_HASH doesn't update
so you could get a situation where you think the program is compiled from an old commit when it isn't

[nazar-pc]

You already know what version you have locally, so I don't think it matters in that case. And if it is not local, then it is installed from git repo and will be treated as a separate crate anyway.

[Steveplays28]

I still think it would be a bug to leave out cargo:rerun-if-changed. If you were to run cargo build and copy the binary for local use, it would contain an incorrect commit hash and date.
It could be confusing to someone in the future.

[Firestar99]

I'm not yet sure if this is a net positive, would love input from others.

Some unordered thoughts:

• I didn't notice cargo gpu on main already stored the commit rev, see cargo gpu show commitsh. Not very discoverable, definitely prefer putting it into the version.
• a cargo package installed from crates.io won't have a git repo, so the git rev will be "unknown"
  • cargo nextest --version also prints the git rev, but also suffers from the same issue when installed via cargo install
  • there doesn't seem to be a nice universal way to handle this
• setting a GIT_HASH env var will force a larger recompile on each rev change
• cargo-deny ci is broken, see #624

[nazar-pc]

My assumption is that this is primarily useful for identifying what version is used when reporting bugs. Versions published on crates.io are well known, while those installed from git may have the same version, but correspond to any revision.

So it is fine to have unknown version for crates.io (I'd probably not set revision at all rather than setting to unknown though) and actual hash when installed from git. And for the same reason it is fine to not have anything when installed from local path since it is something developer will hopefully specify explicitly (they're probably testing some local patches in that case).