Commit assigned to tag section instead of Unreleased section when merging a feature branch

[marcoalessandro]

Describe the bug

A commit made in a separate branch on a date previous to the release tag is included in the tagged section instead of the Unreleased section. The merge happens after the initial tag of the release and the commit still ends up in the released section with the latest tag, instead of the Unreleased section.

To reproduce

• Day 05/25/23 -> Branch feature/my-feature commit xyz
• Day 05/29/23 -> Branch release/14.0 commit abc tagged 14.0.0
• Day 05/30/23 -> Merge branch feature/my-feature into release/14.0

Expected behavior

Unreleased

• Commit xyz

14.0.0

• Commit abc

Observed behavior

14.0.0

• Commit abc
• Commit xyz

Additional context

Thank you in advance for the support, I will remain available for any other clarification or detail.

[welcome]

Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

[charlesrocket]

Same case — post-release commits on feature branches are attributed to the release (charlesrocket/dorst@dc9570c)

[cBulgarelliAtWork]

Any news on this issue?

I am in the same situation too.

Below I have reported a series of steps to reconstruct the problem. I hope they can be helpful.

mkdir project

cd project

git init

echo "READ ME" > README.txt

cat > keepachangelog.toml <<EOL
[changelog]
header = """
# Changelog\n
All notable changes to this project will be documented in this  file.\n
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).\n
"""
body = """
{% if version %}\
    ## [{{ version | trim_start_matches(pat="v") }}] - {{ timestamp | date(format="%Y-%m-%d") }}
{% else %}\
    ## [Unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    ### {{ group | upper_first }}
    {% for commit in commits %}
        - {% if commit.breaking %}[**breaking**] {% endif %}{{ commit.message | upper_first }}\
    {% endfor %}
{% endfor %}\n
"""
trim = true

[git]
conventional_commits = true
filter_unconventional = true
split_commits = false
commit_preprocessors=[
    { pattern = " +", replace = " "}
]
commit_parsers = [
    { message = "^[aA]dd!?:.*", group = "Added"},
    { message = "^[aA]dded!?:.*", group = "Added"},
    { message = "^[dD]eprecate!?:.*", group = "Deprecated"},
    { message = "^[dD]eprecated!?:.*", group = "Deprecated"},
    { message = "^[rR]emove!?:.*", group = "Removed"},
    { message = "^[rR]emoved!?:.*", group = "Removed"},
    { message = "^[fF]ix!?:.*", group = "Fixed"},
    { message = "^[fF]ixed!?:.*", group = "Fixed"},
    { message = "^[sS]ecurity!?:.*", group = "Security"},
    { message = "^[cC]hange!?:.*", group = "Changed"},
    { message = "^[cC]hanged!?:.*", group = "Changed"},
]
protect_breaking_commits = false
filter_commits = true
tag_pattern = ".*"
topo_order = false
sort_commits = "oldest"
EOL

git add .

git commit -m "Add: project initialization"

git checkout -b feature-branch-1

echo "new file" > new_file.txt

git add .

git commit -m "Add: feature 1"

# create a pull request to merge feature-branch-1 into main branch

git checkout main

git tag 1.0.0

git merge feature-branch-1

git tag 1.1.0

After performing these operations, I run the following command, with version 1.2.0 of git-cliff (with macos v.13.4.1):

git cliff -c ./keepachangelog.toml

I get the following result:

# Changelog

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

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

     ## [Unreleased]

### Added

- Project initialization
- Features 1

If I run the command specifying a tag, like below

git cliff -c ./keepachangelog.toml -t 1.0.0

I get the following result:

# Changelog

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

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

     ## [1.0.0] - 2023-07-14

### Added

- Project initialization
- Features 1

In any case, the two features are grouped within the same section, unreleased or 1.0.0.

Instead, using a different CHANGELOG generator, such as auto-changelog (with the command auto-changelog --template keepachangelog), I get the following result:

# Changelog

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

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

Generated by [`auto-changelog`](https://github.com/CookPete/auto-changelog).

## 1.1.0 - 2023-07-14

### Commits

- Add: feature 1

## 1.0.0 - 2023-07-14

### Commits

- Add: project initialization

Features are grouped in tag sections correctly, as I expect.

[bobrik]

#415 addresses this.

[PaulWoitaschek]

Can we get a release for this? This has just caused a big confusion in my company ^^

[orhun]

Sure, I'm preparing for a new release soon!

[PaulWoitaschek]

Thank you! Really awesome work ⭐