Prefer tag creation timestamp in --cooldown-days

[j178]

Use git for-each-ref --sort=-creatordate --format='%(refname:lstrip=2) %(creatordate:unix)' refs/tags to get a list of tags along with their timestamps.
creatordate uses the tag’s creation time if it’s an annotated tag, and if it’s a lightweight tag, it falls back to the commit’s timestamp.

[github-actions]

📦 Cargo Bloat Comparison

Binary size change: +0.00% (16.7 MiB → 16.7 MiB)

Expand for cargo-bloat output

Head Branch Results

 File  .text     Size          Crate Name
 0.6%   1.4% 107.0KiB          prek? <prek::cli::Command as clap_builder::derive::Subcommand>::augment_subcommands
 0.6%   1.2%  98.5KiB           prek prek::languages::<impl prek::config::Language>::run::{{closure}}::{{closure}}
 0.3%   0.7%  54.3KiB           prek prek::archive::unpack::{{closure}}
 0.3%   0.7%  53.0KiB             h2 h2::proto::connection::Connection<T,P,B>::poll
 0.2%   0.5%  40.0KiB           prek prek::languages::<impl prek::config::Language>::install::{{closure}}
 0.2%   0.5%  39.1KiB          prek? <prek::cli::RunArgs as clap_builder::derive::Args>::augment_args
 0.2%   0.5%  38.4KiB           prek prek::run::{{closure}}
 0.2%   0.5%  37.3KiB regex_automata regex_automata::meta::strategy::new
 0.2%   0.4%  35.2KiB           prek prek::workspace::Workspace::discover
 0.2%   0.4%  30.4KiB           prek prek::cli::run::run::run::{{closure}}
 0.2%   0.4%  30.4KiB           std? <core::marker::PhantomData<T> as serde_core::de::DeserializeSeed>::deserialize
 0.2%   0.4%  30.2KiB           prek prek::languages::rust::installer::RustInstaller::install::{{closure}}
 0.2%   0.4%  28.8KiB           prek prek::languages::node::installer::NodeInstaller::install::{{closure}}
 0.2%   0.4%  28.1KiB             h2 h2::proto::connection::DynConnection<B>::recv_frame
 0.2%   0.3%  27.6KiB           prek prek::identify::by_extension::{{closure}}
 0.1%   0.3%  25.1KiB           prek prek::main
 0.1%   0.3%  24.4KiB     hyper_util hyper_util::client::legacy::client::Client<C,B>::send_request::{{closure}}
 0.1%   0.3%  24.4KiB           std? <core::marker::PhantomData<T> as serde_core::de::DeserializeSeed>::deserialize
 0.1%   0.3%  24.3KiB           prek prek::cli::auto_update::update_repo::{{closure}}
 0.1%   0.3%  24.3KiB     hyper_util hyper_util::client::legacy::client::Client<C,B>::connect_to::{{closure}}::{{closure}}::{{closure}}
41.1%  88.9%   6.9MiB                And 10578 smaller methods. Use -n N to show more.
46.2% 100.0%   7.7MiB                .text section size, the file size is 16.7MiB

Base Branch Results

 File  .text     Size          Crate Name
 0.6%   1.4% 107.0KiB          prek? <prek::cli::Command as clap_builder::derive::Subcommand>::augment_subcommands
 0.6%   1.2%  98.5KiB           prek prek::languages::<impl prek::config::Language>::run::{{closure}}::{{closure}}
 0.3%   0.7%  54.3KiB           prek prek::archive::unpack::{{closure}}
 0.3%   0.7%  53.0KiB             h2 h2::proto::connection::Connection<T,P,B>::poll
 0.2%   0.5%  40.0KiB           prek prek::languages::<impl prek::config::Language>::install::{{closure}}
 0.2%   0.5%  39.1KiB          prek? <prek::cli::RunArgs as clap_builder::derive::Args>::augment_args
 0.2%   0.5%  38.4KiB           prek prek::run::{{closure}}
 0.2%   0.5%  37.3KiB regex_automata regex_automata::meta::strategy::new
 0.2%   0.4%  35.2KiB           prek prek::workspace::Workspace::discover
 0.2%   0.4%  30.4KiB           prek prek::cli::run::run::run::{{closure}}
 0.2%   0.4%  30.4KiB           std? <core::marker::PhantomData<T> as serde_core::de::DeserializeSeed>::deserialize
 0.2%   0.4%  30.2KiB           prek prek::languages::rust::installer::RustInstaller::install::{{closure}}
 0.2%   0.4%  28.8KiB           prek prek::languages::node::installer::NodeInstaller::install::{{closure}}
 0.2%   0.4%  28.1KiB             h2 h2::proto::connection::DynConnection<B>::recv_frame
 0.2%   0.3%  27.6KiB           prek prek::identify::by_extension::{{closure}}
 0.1%   0.3%  25.1KiB           prek prek::main
 0.1%   0.3%  24.4KiB     hyper_util hyper_util::client::legacy::client::Client<C,B>::send_request::{{closure}}
 0.1%   0.3%  24.4KiB           std? <core::marker::PhantomData<T> as serde_core::de::DeserializeSeed>::deserialize
 0.1%   0.3%  24.3KiB     hyper_util hyper_util::client::legacy::client::Client<C,B>::connect_to::{{closure}}::{{closure}}::{{closure}}
 0.1%   0.3%  24.2KiB           prek prek::hook::HookBuilder::build::{{closure}}
41.0%  88.9%   6.8MiB                And 10576 smaller methods. Use -n N to show more.
46.2% 100.0%   7.7MiB                .text section size, the file size is 16.7MiB

[codecov]

Codecov Report

❌ Patch coverage is 93.39623% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.81%. Comparing base (b0a25bf) to head (6e2b79f).
⚠️ Report is 4 commits behind head on master.

Files with missing lines	Patch %	Lines
crates/prek/src/cli/auto_update.rs	93.39%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1221      +/-   ##
==========================================
- Coverage   89.81%   89.81%   -0.01%     
==========================================
  Files          79       79              
  Lines       15235    15273      +38     
==========================================
+ Hits        13684    13717      +33     
- Misses       1551     1556       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[potiuk]

There is a very interesting change @j178 -> I am not sure if you realised that - but you can have people asking questions.

I am applying cooldown-days in Airflow in apache/airflow#59395 and I noticed a strange change resulting from autoupdate --freeze in prek 0.2.22:

if you look closer, you will see that hash changed for those two repos, but the version did not.

I tried to find the reason and I was surprised that the hash stored previously cannot be found in commits of the repo, yet - surprisingly git checkout HASH works (and checks out the new commit hash that prek 0.2.22 updated to).

A bit of checking and it turned out that the original hashes were hashes of the TAGS not hashes of the commits they pointed to - those tags were signed and previous auto-update apparently used hashes of the tags not the commits they pointed out to.

That did not change the security properties of it - but the side effect was that if someone actually moved the tags, such pre-commit-config would stop working when installing the hook.

So the change in behaviour is "good" -> now the hashes stored are hashes of committs not tags, so even if somoene moves tags, you will see it with auto-update but the original pre-commit-config will continue to work.

Just wanted you to know about it in case someone else asks - this behaviour change is not described in release notes (I guess because it was not intentional).

[j178]

@potiuk I noticed it, but kinda ignored it haha ^^

This actually came from this commit in #1172, where freeze_revision was extracted into its own function. But I accidentally changed git rev-parse {rev} to git rev-parse {rev}^{}.

According to https://git-scm.com/docs/gitrevisions#Documentation/gitrevisions.txt-revegv0998:

^{}, e.g. v0.99.8^{}
A suffix ^ followed by an empty brace pair means the object could be a tag, and dereference the tag recursively until a non-tag object is found.

So yeah, this wasn’t intentional. But it also doesn’t really have any practical effect. Whether you use the tag object’s hash or the commit’s hash, both refer to immutable objects in the git history — no one can change them anyway.

And honestly, it might even be slightly better. GitHub shows the underlying commit hash for tags on the releases page, so it’s easier for people to verify that the hash matches what GitHub shows.

[j178]

I think I’ll add a test so it doesn’t get changed accidentally again in the future.

[potiuk]

And honestly, it might even be slightly better. GitHub shows the underlying commit hash for tags on the releases page, so it’s easier for people to verify that the hash matches what GitHub shows.

Oh absolutely - it's better this way :) - tag hash is indeed immutable, but the tag itself is not - you can move it even if it is signed and then it will eventually disappear after garbage collection. For commit hash you would have to rewrite the history to make the commit disapper, so yeah - referring commit is definitely better (though security properties are indeed the same).