Firstly of all, thank you very much for this great tool! I really like it.
Describe the bug
When I do release with commit-and-tag-version, it smartly recognise reverted commits and decide version to increment based on the rest of semver commits.
For example, if the commit history has 3 fix: commits and one feat:, but also has one Revert "feat:..." commit, it smartly recognise the reverted one and decide the version, say, 1.0.0 -> 1.0.1, not -> 1.1.0. This is awesome!
However, when I look at the generated CHANGELOG.md, it unfortunately includes the reverted feat: item in the Features section.
Current behavior
The reverted commits are still included in the generated CHANGELOG.md
Expected behavior
The reverted commits should be ignored in the generated CHANGELOG.md just like when the tool decides a new version to increment: 1.0.0 -> 1.0.1
Firstly of all, thank you very much for this great tool! I really like it.
Describe the bug When I do release with commit-and-tag-version, it smartly recognise reverted commits and decide version to increment based on the rest of semver commits.
For example, if the commit history has 3
fix:commits and onefeat:, but also has oneRevert "feat:..."commit, it smartly recognise the reverted one and decide the version, say,1.0.0->1.0.1, not ->1.1.0. This is awesome!However, when I look at the generated
CHANGELOG.md, it unfortunately includes the revertedfeat:item in the Features section.Current behavior The reverted commits are still included in the generated CHANGELOG.md
Expected behavior The reverted commits should be ignored in the generated CHANGELOG.md just like when the tool decides a new version to increment:
1.0.0->1.0.1Environment
commit-and-tag-versionversion(s): 12.2.0Possible Solution
Additional context