Create more tags/releases
waisbrot opened this issue · 8 comments
I'd like to be able to pin to a specific commit without using a SHA. Conversely, the "autoupdate" feature of pre-commit by default pulls the latest tag. So for either of these use-cases, more tags would be helpful.
I believe that Github workflows would make it easy to automatically tag commits, if you'd like to make tags available without any further work from humans. (I can prepare a PR for this if it's an attractive idea)
Thank you for opening this issue!
I think that automatically creating a git tag for every commit ends up making them not all that different from SHAs. It sounds like pre-commit allows you to use --bleeding-edge with autoupdate, which would be equivalent to the default behaviour if every git sha has a tag.
Why do you prefer to use a git tag over a SHA?
Why do you prefer to use a git tag over a SHA?
- A friendlier name. Do I use
9690bb6a1e88f39a6073867b029aa03f0c3ba80cor is9690benough? I don't really want to about that corner of Git. - Understand which one is newer.
9cis more recent than43but older than1a
While the 'bleeding-edge' option exists, the implication is that the hook-author is creating regular releases (that are vetted) and you're choosing to use unreleased versions. Tagging every commit would communicate that every commit is considered a release, in the sense that there's no more ceremony or validation of one commit more than any other.
I would also support having tags as less low-level reference
Just bubbling this back up.
It would be great to add some tags so that pre-commit doesn't complain about pointing at a mutable reference.
We've had a lot of success by writing commits using conventional commit / angular format and then using semantic release to generate all the releases.
I tagged https://github.com/dnephin/pre-commit-golang/releases/tag/v0.5.0 for now
I think it's time for another tag, the last one is approaching a year old