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

FeatureRequest: Commitizen pre-commit hooks #345

Open
1 of 2 tasks
kenibrewer opened this issue Oct 28, 2023 · 1 comment
Open
1 of 2 tasks

FeatureRequest: Commitizen pre-commit hooks #345

kenibrewer opened this issue Oct 28, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@kenibrewer
Copy link
Member

Feature type

  • Add new functionality

  • Change existing functionality

General description of the proposed functionality

Adding commitizen pre-commit hooks will ensure that all commits are properly formatted for updating the CHANGELOG. However, there are potential side-effects of these hooks:

What would happen to PR's which don't abide this (would we disapprove solely based on the commit style)?
Thinking about the end of the PR and getting ready to merge: how are squashes treated with this (would we lose the ability to leverage GitHub's built-in functionality here)?

Originally posted by @d33bs in #340 (comment)

Feature example

Commitizen provides two hooks as show below:

  - repo: https://github.com/commitizen-tools/commitizen
    rev: master
    hooks:
      - id: commitizen
      - stages: [pre-commit]
      - id: commitizen-branch
        stages: [push]

The commitizen hook prevents commits from being completed if they aren't formatted correctly.
The commitzen-branch hook will check all of the commits of a branch prior to them being pushed to the repo.

Alternative Solutions

  • Clear guidance in the CONTRIBUTING.md file
  • Can pre-commit be set to "raise warnings"?
  • Simply have maintainers fix commit messages when merging branches
  • Provide guidance on how to bypass the hooks for people who need that

Additional information

No response

@kenibrewer kenibrewer added the enhancement New feature or request label Oct 28, 2023
@gwaybio
Copy link
Member

gwaybio commented Oct 28, 2023

Thanks Ken, here are my two cents

I would like to keep the barrier to entry low for contributing to the project. I like the idea of this tool supporting CHANGELOGs, but not worth the risk of having someone not contribute b/c of an incorrectly formatted/written commit message. Am I understanding this correctly?

I like the first two alternative solutions, maybe let's do both? In the CONTRIBUTING doc, we can use language that encourages (but not requires) it's use and include setup instructions. I like the "raise warnings" options as it could be instructive for folks to improve their commit messages.

I don't really like the idea of maintainers adjusting commit messages. Maybe every once in a while, but I'd prefer for contributors original messages to be included most of the time, even if they are suboptimal. I'd rather have maintainers adjust the CHANGELOG.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants