Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create more tags/releases #59

Closed
waisbrot opened this issue Aug 25, 2020 · 8 comments
Closed

Create more tags/releases #59

waisbrot opened this issue Aug 25, 2020 · 8 comments

Comments

@waisbrot
Copy link

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)

@dnephin
Copy link
Owner

dnephin commented Sep 3, 2020

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?

@waisbrot
Copy link
Author

waisbrot commented Sep 3, 2020

Why do you prefer to use a git tag over a SHA?

  1. A friendlier name. Do I use 9690bb6a1e88f39a6073867b029aa03f0c3ba80c or is 9690b enough? I don't really want to about that corner of Git.
  2. Understand which one is newer. 9c is more recent than 43 but older than 1a

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.

@obukhov
Copy link

obukhov commented Oct 7, 2020

I would also support having tags as less low-level reference

@greenkiwi
Copy link

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.

@dnephin
Copy link
Owner

dnephin commented Feb 21, 2022

I tagged https://github.com/dnephin/pre-commit-golang/releases/tag/v0.5.0 for now

@sseneca
Copy link

sseneca commented Sep 14, 2022

I think it's time for another tag, the last one is approaching a year old

@dnephin
Copy link
Owner

dnephin commented Oct 2, 2022

@dnephin
Copy link
Owner

dnephin commented Nov 20, 2022

For those who may be interested: #98

@waisbrot waisbrot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants