chore(deps): bump the pre-commit group with 9 updates

[dependabot]

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[jenstroeger]

Investigate why this change has the same version tag with different hashes. The same happens below for flake8 and actionlint.

[jenstroeger]

We introduced the original sha dda8db18cfc68df532abf33b185ecd12d5b7b326 with PR #1156, and I’m almost certainly sure that at that time the sha was the valid commit sha for tag 1.20.0. However, now that original commit sha adamchainz/blacken-docs@dda8db1 does not exist; instead, tag 1.20.0 points at commit adamchainz/blacken-docs@fda7769. ¹ And so, Dependabot now updates the rev to the latest and correct sha while keeping the tag the same.

If I had to make a guess then I’d say that the repo’s history was force-pushed at some point and the tag 1.20.0 was reassigned to a different commit, though I can’t see that in the activities here. @adamchainz might be able to shed some light on this?

Remains the question why pre-commit accepts an invalid rev dda8db1 without a warning and then seems to clone the latest tag:

~/.cache/pre-commit/repo6dn9_crd > git log
commit fda77690955e9b63c6687d8806bafd56a526e45f (grafted, HEAD)
Author: Adam Johnson <me@adamj.eu>
Date:   Mon Sep 8 16:31:35 2025 +0100

    Version 1.20.0

I didn’t find this behavior documented here, and I didn’t find an issue discussing handling of an invalid/nonexistent rev here. However, following the pre-commit code in Store.clone() here I can reproduce the behavior with plain git:

/tmp/bla > git init 
Initialized empty Git repository in /private/tmp/bla/.git/
/tmp/bla > git remote add origin https://github.com/adamchainz/blacken-docs
/tmp/bla > git -c protocol.version=2 fetch origin dda8db18cfc68df532abf33b185ecd12d5b7b326 --depth=1
remote: Enumerating objects: 33, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 33 (delta 0), reused 22 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (33/33), 36.34 KiB | 418.00 KiB/s, done.
From https://github.com/adamchainz/blacken-docs
 * branch            dda8db18cfc68df532abf33b185ecd12d5b7b326 -> FETCH_HEAD
/tmp/bla > git checkout FETCH_HEAD
Note: switching to 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at fda7769 Version 1.20.0
/tmp/bla > git log
commit fda77690955e9b63c6687d8806bafd56a526e45f (grafted, HEAD)
Author: Adam Johnson <me@adamj.eu>
Date:   Mon Sep 8 16:31:35 2025 +0100

    Version 1.20.0

/tmp/bla > cat .git/HEAD 
fda77690955e9b63c6687d8806bafd56a526e45f
/tmp/bla > cat .git/FETCH_HEAD 
dda8db18cfc68df532abf33b185ecd12d5b7b326		'dda8db18cfc68df532abf33b185ecd12d5b7b326' of https://github.com/adamchainz/blacken-docs

If I use a random other commit sha:

/tmp/bla > git -c protocol.version=2 fetch origin c84ac2a20d4da9de5e920603a4d41648ce2cf283 --depth=1
fatal: remote error: upload-pack: not our ref c84ac2a20d4da9de5e920603a4d41648ce2cf283

So git “knows” something here, and I’m still unclear how git manages to connect these two commit shas 🤔

Footnotes

1. Note also that the repo has moved, as per comment here. ↩