-
-
Notifications
You must be signed in to change notification settings - Fork 281
cz ch <tag>
prints the whole changelog if tag_format
is not set
#622
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
Labels
Comments
cz ch
prints all changelog when tag_format
is not setcz ch <tag>
prints all changelog when tag_format
is not set
cz ch <tag>
prints all changelog when tag_format
is not setcz ch <tag>
prints the whole changelog when tag_format
is not set
cz ch <tag>
prints the whole changelog when tag_format
is not setcz ch <tag>
prints the whole changelog if tag_format
is not set
gsalvatella
added a commit
to gsalvatella/commitizen
that referenced
this issue
Nov 27, 2022
The current default setting for `tag_format` is `None`. This is not a problem for the `bump` command, since the `normalize_tag` function defaults to `$version` when no `tag_format` is passed. However it is a problem for the `changelog` command, which seems to explicitly demand a `tag_format` in order to run a rev-range lookup. This creates issues like commitizen-tools#622. Either a sane default needs to be set for `tag_format` or the restriction in `changelog` has to be uplifted.
gsalvatella
added a commit
to gsalvatella/commitizen
that referenced
this issue
Nov 27, 2022
The current default setting for `tag_format` is `None`. This is not a problem for the `bump` command, since the `normalize_tag` function defaults to `$version` when no `tag_format` is passed. However it is a problem for the `changelog` command, which seems to explicitly demand a `tag_format` in order to run a rev-range lookup. This creates issues like commitizen-tools#622. Either a sane default needs to be set for `tag_format` or the restriction in `changelog` has to be uplifted. In this commit the latter has been chosen. Fixes commitizen-tools#622
gsalvatella
added a commit
to gsalvatella/commitizen
that referenced
this issue
Nov 27, 2022
The current default setting for `tag_format` is `None`. This is not a problem for the `bump` command, since the `normalize_tag` function defaults to `$version` when no `tag_format` is passed. However it is a problem for the `changelog` command, which seems to explicitly demand a `tag_format` in order to run a rev-range lookup. This creates issues like commitizen-tools#622. Either a sane default needs to be set for `tag_format` or the restriction in `changelog` has to be uplifted. In this commit the latter has been chosen. A test is also implemented to check that `changelog` will always compute a rev range with the default tag format. Fixes commitizen-tools#622
4 tasks
gsalvatella
added a commit
to gsalvatella/commitizen
that referenced
this issue
Nov 29, 2022
The current default setting for `tag_format` is `None`. This is not a problem for the `bump` command, since the `normalize_tag` function defaults to `$version` when no `tag_format` is passed. However it is a problem for the `changelog` command, which seems to explicitly demand a `tag_format` in order to run a rev-range lookup. This creates issues like commitizen-tools#622. Either a sane default needs to be set for `tag_format` or the restriction in `changelog` has to be uplifted. In this commit the latter has been chosen. A test is also implemented to check that `changelog` will always compute a rev range with the default tag format. Fixes commitizen-tools#622
gsalvatella
added a commit
to gsalvatella/commitizen
that referenced
this issue
Nov 29, 2022
The current default setting for `tag_format` is `None`. This is not a problem for the `bump` command, since the `normalize_tag` function defaults to `$version` when no `tag_format` is passed. However it is a problem for the `changelog` command, which seems to explicitly demand a `tag_format` in order to run a rev-range lookup. This creates issues like commitizen-tools#622. Either a sane default needs to be set for `tag_format` or the restriction in `changelog` has to be uplifted. In this commit the latter has been chosen. A test is also implemented to check that `changelog` will always compute a rev range with the default tag format. Fixes commitizen-tools#622
adam-grant-hendry
pushed a commit
to adam-grant-hendry/commitizen
that referenced
this issue
Dec 3, 2022
The current default setting for `tag_format` is `None`. This is not a problem for the `bump` command, since the `normalize_tag` function defaults to `$version` when no `tag_format` is passed. However it is a problem for the `changelog` command, which seems to explicitly demand a `tag_format` in order to run a rev-range lookup. This creates issues like commitizen-tools#622. Either a sane default needs to be set for `tag_format` or the restriction in `changelog` has to be uplifted. In this commit the latter has been chosen. A test is also implemented to check that `changelog` will always compute a rev range with the default tag format. Fixes commitizen-tools#622
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Removing the
tag_format
config from thepyproject.toml
results in commitizen not being able to read the changelog for specific tags (it always prints the whole changelog). Iftag_format
is a required parameter it should be noted in the documentation. Otherwisetag_format
should default to$version
, since this is how it is initialized.This can cause a lot of confusion for existing projects that are introducing commitizen in their workflows without using
cz init
and didn't addtag_format
explicitly in thepyproject.toml
.Steps to reproduce
Give the following example setup
Now check the changelog of the latest version
Remove
tag_format
line frompyproject.toml
Check again
Current behavior
Desired behavior
Screenshots
No response
Environment
cz version: 2.37.0
python version: 3.10.8
The text was updated successfully, but these errors were encountered: