-
-
Notifications
You must be signed in to change notification settings - Fork 198
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
Strange behaviour with "parallel" codelines #29
Comments
Hello! Thanks for reporting this. I can say that this is not the indented behaviour for this case. Using I created the following commit history for reproducing this issue:
When
So it creates this changelog:
Chronologically, this is correct because
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 000a67c. And this can be made easily opt-out with an extra flag. That's why I added So now
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: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: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! 🤗
The text was updated successfully, but these errors were encountered: