History of hotfix gets combined with unreleased section

[Pyth0ff]

First of all I really like the simplicty of git-cliff, but I encountered an issue where I don't know, if we are using it correct or not. It sounds like a little bit like #29, but I'm not sure.

Description
In the project I'm working on we have a git-flow like branching model at the moment. We created from develop the version v1.0.0 and merged these changes to master. Afterwards we continued our work on v1.1.0 on develop in the meanwhile, but later an urgent issue for v1.0.0 occured and we had to create an hotfix v1.0.1.

We created an branch hotfix/1.0.1 from master and merged these changes back to master and develop, but on develop the work continued and after the merge of hotfix/1.0.1 into develop the changelog now combines the changes from the hotfix with the unreleased changes on develop.

Actual Output

*   1473da8 (HEAD -> develop) Merge branch 'hotfix/1.0.1' into develop
|\  
| * 6134a57 (tag: v1.0.1, master, hotfix/1.0.1) fix: v1.0.1
* | 5ce33a7 chore: start work on v1.1.0
|/  
* a6915e6 (tag: v1.0.0) feat: v1.0.0

The corresponding changelog looks like this:

# Changelog
All notable changes to this project will be documented in this file.

## [1.0.1] - 2021-12-01

### Bug Fixes

- v1.0.1

### Miscellaneous Tasks

- Start work on v1.1.0

## [1.0.0] - 2021-11-01

### Features

- v1.0.0

Expected Output

# Changelog
All notable changes to this project will be documented in this file.

## [unreleased]

### Miscellaneous Tasks

- Start work on v1.1.0

## [1.0.1] - 2021-12-01

### Bug Fixes

- v1.0.1

## [1.0.0] - 2021-11-01

### Features

- v1.0.0

Question
How can we prevent that the hotfix changes an the unreleased changes are combined by their commit date?

[orhun]

Hello!

When I look at the git history, changelog makes sense.

First, v1.0.0 is created and it has only one commit. So this part is correct:

## [1.0.0] - 2021-12-11
### Features
- V1.0.0

Then, you committed chore: start work on v1.1.0 and then realized there is something wrong with v1.0.0 so checked out to a new branch called hotfix/1.0.1. You created one commit there (fix: v1.0.1) and merged it with develop and master after creating a tag (v1.0.1).

So v1.0.1 has 2 commits:

## [1.0.1] - 2021-12-11
### Bug Fixes
- V1.0.1
### Miscellaneous Tasks
- Start work on v1.1.0

In this case, chore: start work on v1.1.0 is not really an "unreleased" commit because it belongs to a tag which is 1.0.1:

$ git tag --contains $(git log --pretty=format:"%h" --all --grep='start work on v1.1.0')
v1.0.1

How can we prevent that the hotfix changes an the unreleased changes are combined by their commit date?

I can't really see a problem about the changelog here :/ That's why I can't answer your question.

---

I used the following script to reproduce the git history, let me know if I missed something:

git init
git checkout -b develop
git commit --allow-empty -m "feat: v1.0.0"
git tag v1.0.0

git checkout -b master
git commit --allow-empty -m "chore: start work on v1.1.0"

git checkout -b hotfix/1.0.1
git commit --allow-empty -m "fix: v1.0.1"
git tag v1.0.1

git checkout master
git merge hotfix/1.0.1

git checkout develop
git merge --no-ff hotfix/1.0.1

Results in:

$ git log --graph --decorate --oneline --all
*   95dffa5 (HEAD -> develop) Merge branch 'hotfix/1.0.1' into develop
|\  
| * 19b11a5 (tag: v1.0.1, master, hotfix/1.0.1) fix: v1.0.1
| * 63b9805 chore: start work on v1.1.0
|/  
* a5c4ec6 (tag: v1.0.0) feat: v1.0.0

[mstefanini]

Hello!

I've found the same problem using one-flow in my company. To be more clear this is the actual tree (without the commit message)

* | 27140a9d Merge branch 'hotfix/0.1.2'
|\|
| * 022a4b39 (tag: 0.1.2)
| * 53facfc6 
* | a0d128ef Merge branch 'hotfix/0.1.1'
|\|
| * 7f3a1138 (tag: 0.1.1) 
| * bcd19c61
| * 3cbd184b
| * 6a595cea
| * 95dad508
| * 13629cdf
| * e63b69fc 
| * 2e189876 
| * 1b73f166 
* | fd2b4867 
* | 6ab9686d 
* | 76450746 
* | 9a76ce27 
* | 02e66f25 
* | 88513cf2 
* |   f5f555ff Merge branch 'release/0.1.0'
| *   e836919f (release/0.1.0)

The changelogs created internally in the hotfix branches (that are tagged from 0.1.1 and 0.1.2) were built correctly with only 53facfc6 for 0.1.2 and 1b73f166...bcd19c61 for the 0.1.1.
But after the last merge when we try to generate a changelog from the master branch the range of commits between the release merge (f5f555ff) and the tags (this is the rage: 88513cf2...fd2b4867) are inserted under the 0.1.1 version which is not the truth for the project.

That sounds like the problem described by @Pyth0ff

[bobrik]

#415 addresses this.