I'd like to put in git's pre-commit hook a quick check that makes sure that the Cargo.lock is up to date.
I do not however want to actually build anything as it can take a while. so cargo check --frozen is not ideal. Some kind of cargo check --frozen --dry-run would be great.
I played a bit with it now, and I'm very confused. It seems to be behaving somewhat like cargo update?
Let me explain in more details what I'm after:
Sometimes I'll make a change in Cargo.toml that is very trivial, and then just git commit -a && git push and since I never updated Cargo.lockby running cargo build to match by Cargo.tomls changes, now the CI might experience weird behavior (e.g. have to do the Cargo.lock change each time).
From what I can tell cargo generate-lockfile --frozen --offline and cargo generate-lockfile --frozen complain that "Cargo.lock needs to be updated", but when I actually run cargo build, Cargo.lock doesn't change. So somewhat like cargo update, it seems to want to do actual package updates (which github's dependabot takes care for us already).
So yeah - I'm only after ensuring Cargo.lock is matching current Cargo.toml, and not updating dependencies itself.
Coming at this particular part from the other direction, you could use cargo build --locked in CI to cause a rapid failure if Cargo.lock is out of date compared to Cargo.toml.
That doesn't fix the problem, but does mean that CI won't experience "weird behaviour", since CI will consistently fail due to out of date lockfiles.