pre-commit autoupdate tag confusion

[sadikkuzu]

I use typos as pre-commit hook in my repo.

When I run pre-commit autoupdate, I get this result:

pre-commit autoupdate
Updating https://github.com/crate-ci/typos ... updating v1.3.1 -> typos-v0.8.2.

On the other hand, I want to get v1.3.3 as displayed in https://github.com/crate-ci/typos/blob/master/docs/pre-commit.md

Is there anything i/you can do? Thanks in advance.

[epage]

I suspect it did upgrade to v1.3.3, it was just done in a confusing way.

From the docs

You can update your hooks to the latest version automatically by running pre-commit autoupdate. By default, this will bring the hooks to the latest tag on the default branch.

There are multiple packages in the default branch and we tag each one. When release 1.3.3, the tags v1.3.3 and typos-v0.8.2 were added. They both point to the same version.

That is still unfortunate. Maybe I should stop tagging each of the packages...

[sadikkuzu]

I think it's ok now. Thanks a lot!

$ pre-commit autoupdate
Updating https://github.com/crate-ci/typos ... updating v1.3.3 -> v1.3.4.

[sadikkuzu]

Hi @epage This issue is still going on:

$ pre-commit autoupdate
Updating https://github.com/crate-ci/typos ... updating v1.3.3 -> typos-v0.8.6.

Expected result:

$ pre-commit autoupdate
Updating https://github.com/crate-ci/typos ... updating v1.3.3 -> v1.4.1.

[epage]

This was never truly "fixed" because its a race condition in how tagging is done and how pre-commit treats tags.

Note that this is superficial, you are still running the latest version since all of these tags point to the same commit.

[sadikkuzu]

Since pre-commit autoupdate uses similar to:

git describe --abbrev=0

is it possible to set v*.*.* tag lastly to corresponding commit?

$ git tag -l --sort=-creatordate | head -n 20
typos-dict-v0.8.8
typos-v0.10.3
typos-vars-v0.8.5
typos-dict-v0.8.7
typos-vars-v0.8.4
varcon-v0.6.4
typos-dict-v0.8.6
v1.11.1
v1.11.0
dictgen-v0.2.3
typos-dict-v0.8.5
typos-v0.10.2
typos-vars-v0.8.3
varcon-core-v2.2.5
varcon-v0.6.3
typos-dict-v0.8.4
v1.10.3
v1.10.2
v1.10.1
v1.10.0

---

$ git describe --abbrev=0
typos-dict-v0.8.8

[epage]

I do not know of a way to control the ordering of the tags to make this work better with pre-commit

[sadikkuzu]

I do not know of a way to control the ordering of the tags to make this work better with pre-commit

I'm asking to understand, what is the current ordering of the tags?

I think giving last tag as v1.xx.xx will handle this situation.

git tag typos-dict-xxx
git tag typos-vars-xxx
git push --tags
git tag v1.12.2
git push --tags

Because there were times that it was ok: https://github.com/crate-ci/typos/issues/390#issuecomment-1014780375

As an alternative,

...
git commit --allow-empty -m "v1.12.2"
git tag v1.12.2
git push --tags

[epage]

The tags are applied in release-order.

Because there were times that it was ok: https://github.com/crate-ci/typos/issues/390#issuecomment-1014780375

To which I replied

This was never truly "fixed" because its a race condition in how tagging is done and how pre-commit treats tags.

[max-sixty]

Not sure how helpful a "me too!" comment is, but we're getting this with typos-dict in https://github.com/max-sixty/pytest-accept/pull/87/files.

So to the extent you're considering harmonizing the version numbers (we do this in PRQL, makes releasing much easier FWIW! Though I'm saying this without your context), that would solve this issue.

And thanks again for typos — it's really excellent. Would love to see it grow more, every time my VSCode spell check gets a false positive, I wistfully think of typos...

[zaufi]

Hit this issue too:

…
[https://github.com/crate-ci/typos] updating v1.22.9 -> typos-v0.10.26

I understand that at least typos-v0.10.26 now is the same as v1.23.2 but it would be nice to avoid further updates that will revert back to the v* scheme from typos-v* (cuz I see that typos-v* tags are not always set for v* releases)...

How can I not have typos-v* tags in my pre-commit config?! This is so inconvenient!