If I have a project where tags are also created on side branches and not only on the master branch, git cliff seems to get confused, if the --unreleased flag is used.
I would expect to see only commit messages parsed that do not belong to a commit, but this does not seem to be the case.
If on a side branch a new tag was created to fix a older version also already tagged commits form the master branch start to appear in the change log. It seams the last commit in time on any branch is used to determine the unreleased commits.
Steps To Reproduce
Create tag 2.0.0 on branch master
Create tag 1.0.1 on branch e.g. release/1
Create tag 2.1.0 on head of master
Add new commit on master
Create a change log on master with git cliff -u
Expected behavior
It is expected that only the newly created commit on master appears in the change log, created by git cliff.
But what I see instead, that also the commits of the tag 2.0.0 are included.
Screenshots / Logs
Software information
Operating system: WSL - Ubuntu 22.04
Rust version:
Project version: 2.4.0
Additional context
As soon as a new tag is created on the master branch, the behavior is again as expected.
Is there an existing issue for this?
Description of the bug
If I have a project where tags are also created on side branches and not only on the master branch, git cliff seems to get confused, if the
--unreleased
flag is used. I would expect to see only commit messages parsed that do not belong to a commit, but this does not seem to be the case. If on a side branch a new tag was created to fix a older version also already tagged commits form the master branch start to appear in the change log. It seams the last commit in time on any branch is used to determine the unreleased commits.Steps To Reproduce
2.0.0
on branchmaster
1.0.1
on branch e.g.release/1
2.1.0
on head ofmaster
master
master
withgit cliff -u
Expected behavior
It is expected that only the newly created commit on
master
appears in the change log, created by git cliff.But what I see instead, that also the commits of the tag 2.0.0 are included.
Screenshots / Logs
Software information
Additional context
As soon as a new tag is created on the
master
branch, the behavior is again as expected.