Bug Report

Description

First of all, thank you for a great tool, you did an amazing work!

I have a usual flow with GitHub action that is running after the merge (exactly the one that is described indocumentation). And it looks like in case of merge commits it can produce empty release and changelog, but still bump a version.
I havemain branchandfeature` branch. The history looks like this

*   v1.2.0 release (main)*   Merge `feature into `main`|  \|   *   Merge 'main' into 'feature' to get latest changes (feature)| / ||   |  *   |    v1.1.0 release (main)*   |    Some commit in main|   ||   *   feat: My new feature (feature)|  /  |

Expected behavior

v1.2.0 release is created, release containsfeat: My new feature commit in changelog and release.

Actual behavior

v1.2.0 release is created, but CHANGELOG.md and GitHub release are empty, they don't containfeat: My new feature, just blank

## v1.2.0 (2025-05-23)

Environment

• Operating System (w/ version): Ubuntu 25.04
• Python version: 3.10
• Pip version: 25.1.1
• Semantic-release version: 9.21.1
• Build tool (w/ version): None

Configuration

[tool.semantic_release]version_toml = ["pyproject.toml:project.version"][tool.semantic_release.changelog]mode ="update"

Additional context

As I understand, the problem is not inpython-semantic-release directly; the problem is thegit log output format. Even withtopo_order=True here, it still puts myfeat: My new feature commit before thev1.1.0 release commit in the history. It looks like after theMerge 'main' into 'feature' to add the latest changes commit, thegit log command decided to show commits frommain before showing commits fromfeature.

Why the PR title mentions inconsistency is because in the version resolving logic, the_traverse_graph_for_commits() function returns the correct list of new commits since the last release.
As a result, the version is calculated correctly, but there are no new commits in the release history, so the changelog and release notes are empty.

An obvious idea would be to use_traverse_graph_for_commits()-like logic inReleaseHistory.from_git_history() to getunreleased commits. But I assume it's not that simple, or it would have been implemented this way already.
I'm happy to provide more info or prepare a PR if you have an idea of how to deal with this behavior.