You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This page contains frequently asked questions about Commitizen.
1
+
This page contains frequently asked how to questions.
2
2
3
3
## Support for [`PEP621`](https://peps.python.org/pep-0621/)
4
4
@@ -23,15 +23,6 @@ version = "2.5.1"
23
23
version_provider = "pep621"
24
24
```
25
25
26
-
## Why are `revert` and `chore` valid types in the check pattern of `cz_conventional_commits` but not types we can select?
27
-
28
-
`revert` and `chore` are added to the `pattern` in `cz check` in order to prevent backward errors, but officially they are not part of conventional commits, we are using the latest [types from Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) (they used to but were removed).
29
-
However, you can create a customized `cz` with those extra types. (See [Customization](customization/config_file.md)).
If for any reason, the created tag and changelog were to be undone, this is the snippet:
@@ -50,87 +41,24 @@ In case the commit was pushed to the server, you can remove it by running:
50
41
git push --delete origin <created_tag>
51
42
```
52
43
53
-
## Is this project affiliated with the [Commitizen JS][cz-js] project?
54
-
55
-
**It is not affiliated.**
56
-
57
-
Both are used for similar purposes, parsing commits, generating changelog and version we presume.
58
-
This one is written in python to make integration easier for python projects and the other serves the JS packages.
59
-
60
-
<!-- TODO: Add more details about the differences between Commitizen and Commitizen JS -->
61
-
62
-
They differ a bit in design, not sure if cz-js does any of this, but these are some things you can do with our Commitizen:
63
-
64
-
- create custom rules, version bumps and changelog generation. By default, we use the popular conventional commits (I think cz-js allows this).
65
-
- single package, install one thing and it will work. cz-js is a monorepo, but you have to install different dependencies as far as I know.
66
-
- pre-commit integration
67
-
- works on any language project, as long as you create the `.cz.toml` or `cz.toml` file.
68
-
69
-
Where do they cross paths?
70
-
71
-
If you are using conventional commits in your git history, then you could swap one with the other in theory.
72
-
73
-
Regarding the name, [cz-js][cz-js] came first, they used the word Commitizen first. When this project was created originally, the creator read "be a good commitizen", and thought it was just a cool word that made sense, and this would be a package that helps you be a good "commit citizen".
74
-
75
44
## How to handle revert commits?
76
45
77
46
```sh
78
47
git revert --no-commit <SHA>
79
48
git commit -m "revert: foo bar"
80
49
```
81
50
82
-
## Why don't we use [Pydantic](https://docs.pydantic.dev/)?
83
-
84
-
While Pydantic is a powerful and popular library for data validation, we intentionally avoid using it in this project to keep our dependency tree minimal and maintainable.
85
-
86
-
Including Pydantic would increase the chances of version conflicts for users - especially with major changes introduced in Pydantic v3. Because we pin dependencies tightly, adding Pydantic could unintentionally restrict what other tools or libraries users can install alongside `commitizen`.
87
-
88
-
Moreover we don't rely on the full feature set of Pydantic. Simpler alternatives like Python's built-in `TypedDict` offer sufficient type safety for our use cases, without the runtime overhead or dependency burden.
89
-
90
-
In short, avoiding Pydantic helps us:
91
-
- Keep dependencies lightweight
92
-
- Reduce compatibility issues for users
93
-
- Maintain clarity about what contributors should and shouldn't use
94
-
95
-
96
51
## I got `Exception [WinError 995] The I/O operation ...` error
97
52
98
53
This error was caused by a Python bug on Windows. It's been fixed by [cpython #22017](https://github.com/python/cpython/pull/22017), and according to Python's changelog, [3.8.6rc1](https://docs.python.org/3.8/whatsnew/changelog.html#python-3-8-6-release-candidate-1) and [3.9.0rc2](https://docs.python.org/3.9/whatsnew/changelog.html#python-3-9-0-release-candidate-2) should be the accurate versions first contain this fix. In conclusion, upgrade your Python version might solve this issue.
99
54
100
55
More discussion can be found in issue [#318](https://github.com/commitizen-tools/commitizen/issues/318).
101
56
102
-
## Why does Commitizen not support CalVer?
103
-
104
-
`commitizen` could support CalVer alongside SemVer, but in practice implementing CalVer
105
-
creates numerous edge cases that are difficult to maintain ([#385]) and more generally,
106
-
mixing the two version schemes may not be a good idea. If CalVer or other custom
107
-
versioning scheme is needed, `commitizen` could still be used to standardize commits
108
-
and create changelogs, but a separate package should be used for version increments.
109
-
110
-
Mixing CalVer and SemVer is generally not recommended because each versioning scheme
111
-
serves a different purpose. Diverging from either specification can be confusing to
112
-
users and cause errors with third-party tools that don't expect the non-standard format.
113
-
114
-
In the future, `commitizen` may support some implementation of CalVer, but at the time
115
-
of writing, there are no plans to implement the feature ([#173]).
116
-
117
-
If you would like to learn more about both schemes, there are plenty of good resources:
This page contains features that have been proposed or considered but won't be implemented in Commitizen.
1
+
# Feature request graveyard
2
+
3
+
This page contains features and designs that have been proposed or considered but won't be implemented in Commitizen.
2
4
3
5
For a comprehensive list, please refer to our [issue tracker](https://github.com/commitizen-tools/commitizen/issues?q=is:issue%20state:closed%20label:%22issue-status:%20wont-fix%22%20OR%20label:%22issue-status:%20wont-implement%22).
4
6
5
-
- Enable multiple locations of config file `.cz.*`[#955](https://github.com/commitizen-tools/commitizen/issues/955)
6
-
- Create a flag to build the changelog from commits in multiple git repositories [#790](https://github.com/commitizen-tools/commitizen/issues/790)
7
-
- Global Configuration [#597](https://github.com/commitizen-tools/commitizen/issues/597)
7
+
## Enable multiple locations of config file `.cz.*`[#955](https://github.com/commitizen-tools/commitizen/issues/955)
8
+
9
+
<!-- TODO: Add more details about why we won't add this feature -->
10
+
11
+
## Create a flag to build the changelog from commits in multiple git repositories [#790](https://github.com/commitizen-tools/commitizen/issues/790)
12
+
13
+
<!-- TODO: Add more details about why we won't add this feature -->
14
+
15
+
## Global Configuration [#597](https://github.com/commitizen-tools/commitizen/issues/597)
16
+
17
+
<!-- TODO: Add more details about why we won't add this feature -->
18
+
19
+
## Why are `revert` and `chore` valid types in the check pattern of `cz_conventional_commits` but not types we can select?
20
+
21
+
`revert` and `chore` are added to the `pattern` in `cz check` in order to prevent backward errors, but officially they are not part of conventional commits, we are using the latest [types from Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) (they used to but were removed).
22
+
However, you can create a customized `cz` with those extra types. (See [Customization](customization/config_file.md)).
## Why don't we use [Pydantic](https://docs.pydantic.dev/)?
60
+
61
+
While Pydantic is a powerful and popular library for data validation, we intentionally avoid using it in this project to keep our dependency tree minimal and maintainable.
62
+
63
+
Including Pydantic would increase the chances of version conflicts for users - especially with major changes introduced in Pydantic v3. Because we pin dependencies tightly, adding Pydantic could unintentionally restrict what other tools or libraries users can install alongside `commitizen`.
64
+
65
+
Moreover we don't rely on the full feature set of Pydantic. Simpler alternatives like Python's built-in `TypedDict` offer sufficient type safety for our use cases, without the runtime overhead or dependency burden.
66
+
67
+
In short, avoiding Pydantic helps us:
68
+
69
+
- Keep dependencies lightweight
70
+
- Reduce compatibility issues for users
71
+
- Maintain clarity about what contributors should and shouldn't use
## Is this project affiliated with the [Commitizen JS][cz-js] project?
3
+
4
+
**It is not affiliated.**
5
+
6
+
Both are used for similar purposes, parsing commits, generating changelog and version we presume.
7
+
This one is written in python to make integration easier for python projects and the other serves the JS packages.
8
+
9
+
<!-- TODO: Add more details about the differences between Commitizen and Commitizen JS -->
10
+
11
+
They differ a bit in design, not sure if cz-js does any of this, but these are some things you can do with our Commitizen:
12
+
13
+
- create custom rules, version bumps and changelog generation. By default, we use the popular conventional commits (I think cz-js allows this).
14
+
- single package, install one thing and it will work. cz-js is a monorepo, but you have to install different dependencies as far as I know.
15
+
- pre-commit integration
16
+
- works on any language project, as long as you create the `.cz.toml` or `cz.toml` file.
17
+
18
+
Where do they cross paths?
19
+
20
+
If you are using conventional commits in your git history, then you could swap one with the other in theory.
21
+
22
+
Regarding the name, [cz-js][cz-js] came first, they used the word Commitizen first. When this project was created originally, the creator read "be a good commitizen", and thought it was just a cool word that made sense, and this would be a package that helps you be a good "commit citizen".
0 commit comments