Repository navigation
Enable cover cz_conventional_commits via [tool.commitizen.customize] #1270
Description
Activity
Needs more information and examples. I don't understand what have you tried to do
sorry for lack of enough context.
in short,I found that the
changelogdid not include total commit records(only fix feat etc)i wanna simply keep the current configuration and cover the
attrthat defines which commit should be involved inchangelogwithtomlextra configgiven official config and then cover it,but now we can not cover a bit
customconfig withtomluntil the completecustomconfig Intomlhope it will clarify my feature request.😄
- changed the title
[-]Enable toml cover custom settings[/-][+]Enable toml cover partial custom settings[/+]on Oct 23, 2024 But what did you already do? Can you share the toml that didn't work?
This is a very common case and it's documented here:
https://commitizen-tools.github.io/commitizen/customization/#1-customize-in-configuration-filecommit_parser = "^(?P<change_type>feature|bug fix):\\s(?P<message>.*)?" changelog_pattern = "^(feature|bug fix)?(!)?" change_type_map = {"feature" = "Feat", "bug fix" = "Fix"}- changed the title
[-]Enable toml cover partial custom settings[/-][+] Enable cover cz_conventional_commits via [tool.commitizen.customize][/+]on Oct 23, 2024 all finished but docs in #1274!
if you guys find it really different to customize, I recommend git-cliff or git-changelog.
it would help a lot😊
I think we should continue with this. It makes sense to allow the modification of an existing provider.
Right @Lee-W @noirbizarre ?Maybe instead of breaking
tool.commitizen.customizewe could create a new one:tool.commitizen.rules.
Which would override the existing commitizen definition:[tool.commitizen.rules] commit_parser = "^((?P<change_type>feat|fix|refactor|perf|docs|style|refactor|ci|BREAKING CHANGE)(?:\\((?P<scope>[^()\r\n]*)\\)|\\()?(?P<breaking>!)?|\\w+!):\\s(?P<message>.*)?" changelog_pattern = "^((BREAKING[\\-\\ ]CHANGE|\\w+)(\\(.+\\))?!?):" change_type_map = {"feat"="Feat","fix"="Fix","refactor"= "Refactor","perf"="Perf","docs"="Docs","style"="Style","ci"="CI"}Thoughts?
Yep, I think we should do it. We probably could make the rule a column of
tool.commitizen.customize? If not provided, then it'll work as it is now. If provided, it'll inherit from that cz rule. Might need to do some import or class magic for this, but probably worth exploring 🤔For visibility: PR #1570 (open) is the in-flight implementation of
[tool.commitizen.customize]-style overrides forcz_conventional_commits. It's been waiting for review since 2025-08; reviving it would unblock both this issue and the broader umbrella in #1278.Surfaced via the round-2 triage in #1965 — flagging that the implementation pathway exists but is review-bound.
Description
hey there👋 it's a fantastic cil tools. thanks for your guys contribution!
it's impossible to cover the default options such as commit Patten via toml after checking the docs and raw code,only will work on complicated full customization in toml which is scary.
😭
the following is the version i would like to use:
of course,
[tool.commitizen.customize]would be invalid because of[tool.commitizen]nameis notcz_customizeaccording to the docs and raw code.it looks like we coverd
cz_conventional_commitsversion with[tool.commitizen.customize],which is what we need.so let's replace the
nameascz_customize, it will work oncz bump --dry-run,butcz commit -awould failed for no complete definition[tool.commitizen.customize],also docs had given the complete one looks terrified.Possible Solution
i think we can realize it via making
class CustomizeCommitsCz:to inherit fromConventionalCommitsCzdirectly.