Closed arthrarnld closed 2 years ago
Hello! Thanks for reporting this.
I can say that this is not the indented behaviour for this case. Using -u
should not include any tagged commits in the changelog.
I created the following commit history for reproducing this issue:
* f95ee65 (tag: v0.1.1, fix_v1) fix: patch on v0.1.x
| * 709faef (HEAD -> master) feat: fifth commit on master
| * 8da0f06 (tag: v0.2.0) feat: fourth commit on master
| * 527cefd chore: third commit on master
|/
* a9f6323 (tag: v0.1.0) fix: second commit on master
* 2c9cadb feat: first commit on master
When -u
is specified, git-cliff
implicitly uses the following portion of the commit history:
f95ee65..HEAD
So it creates this changelog:
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Features
- Fifth commit on master
## [0.2.0] - 2021-10-29
### Features
- Fourth commit on master
### Miscellaneous Tasks
- Third commit on master
<!-- generated by git-cliff -->
Chronologically, this is correct because f95ee65
is the last tagged commit:
But from the practical standpoint, doing this will obviously include the previously tagged commits. So for your use case, tags should be used by their "appearance order" in the commit history. Like this:
While searching for the roots of this issue, I realized this happens due to 000a67cd8aae7ae20848baa04cd6212376dcde12. And this can be made easily opt-out with an extra flag.
That's why I added --topo-order
flag in cc09d637ff4edfcba625e469dcd3eb0062ac2a4f which sorts the tags in topological order (children before parents). I believe this flag will be useful for similar scenarios as well.
So now git cliff --unreleased --topo-order
will give you the expected result:
# Changelog
All notable changes to this project will be documented in this file.
## [unreleased]
### Features
- Fifth commit on master
<!-- generated by git-cliff -->
Lastly, this flag will be available in the upcoming release so feel free to try it out and report bugs by either pulling the docker image or building from source.
Let me know if you have any questions/suggestions/ideas 🐻
(PS: Sorry for the late reply, I've been dealing with a job change + school stuff)
Describe the bug Hey! I'm seeing some odd results when generating a changelog if the most recent tag (chronologically) is not in the same version line. I'm not sure if it's something I'm doing wrong... 🤔
To Reproduce
master
as follows (most recent on top, as pergit log
:v0.1.x
line, so I checked out the tag, started a new branch and made a commit:When I generate the changelog for
v0.1.1
, I get the result I expected ("Patch on v0.1.x"), however the changelog for the unreleased commit on master is not:Using
git cliff v0.2.0..
instead does give me the expected result.Expected behavior I expected the output of
git cliff -u
to be the same asgit cliff v0.2.0..
in this case:If this is the intended behaviour, just let me know and I'll adapt our CI jobs to use the explicit git refspec. Thanks! 🤗