Inconsistent changelog behavior based on rev-range & merge strategy

[sacha-c]

Description

We are running into inconsistent behavior of the changelog command depending on the rev-range used when we have a branch with different merge commits.

The reason is that when generating the changelog, commitizen is using the author-date-order (see here)

This means that in the scenario where you merge using a non-linear merge strategy (which is often the default), then the changelog command become inconsistent. (See examples below)

Steps to reproduce

Here is an example (you can find this example in a test github repo here:

1. Create a main branch with an initial commit with commitizen setup & a cz bump commit v0.1.0
2. Create mr 1 off of main & make a commit
3. Create mr2 off of main & make a commit
4. Merge mr1 into main with git merge mr1
5. Run cz bump (tags v0.2.0)
6. Merge mr2 into main with git merge mr2
7. Run cz bump (tags v0.3.0)

We end up with the following git tree:

(venv) ***@*** commitizen_changelog_bug_example % git log --graph --oneline --all
* a48e0e5 (HEAD -> main, tag: v0.3.0, origin/main) bump: version 0.2.0 → 0.3.0
*   d247ed7 Merge branch 'mr2'
|\  
| * 36b659e (origin/mr2, mr2) feat: mr2
* | 7b97d2c (tag: v0.2.0) bump: version 0.1.0 → 0.2.0
* | 82f3844 (origin/mr1, mr1) feat: mr1
|/  
* 1162498 (tag: v0.1.0) bump: version 0.0.1 → 0.1.0
* e76ef76 feat: initial commit

The expectation now is for cz changelog v0.3.0 & cz changelog v0.2.0..v0.3.0 to show the same content for v0.3.0, but it is not the case. Because commitizen orders commits by author_date, when using a rev-range it is ordering commits by date, which makes the commit from mr2 erroneously appear in v0.2.0. However when using a single rev it appears as expected.
Here is the output of the different commands

(venv) ***@*** commitizen_changelog_bug_example % cz changelog v0.3.0 --dry-run
## v0.3.0 (2023-01-26)

### Feat

- mr2

(venv) ***@*** commitizen_changelog_bug_example % cz changelog v0.2.0 --dry-run
## v0.2.0 (2023-01-26)

### Feat

- mr1

(venv) ***@*** commitizen_changelog_bug_example % cz changelog v0.2.0..v0.3.0 --dry-run
## v0.3.0 (2023-01-26)

## v0.2.0 (2023-01-26)

### Feat

- mr2
- mr1

Current behavior

Running cz changelog v0.3.0 & cz changelog v0.2.0..v0.3.0 gives a different output under the v0.3.0 entry

Desired behavior

Running cz changelog v0.3.0 & cz changelog v0.2.0..v0.3.0 gives the same output under the v0.3.0 entry

Screenshots

No response

Environment

Commitizen Version: 2.40.0
Python Version: 3.10.9 (main, Dec 27 2022, 11:11:24) [Clang 14.0.0 (clang-1400.0.29.202)]
Operating System: Darwin

Proposed solutions/ideas

I think the solution would be to change

commits = git.get_commits(
-    start=start_rev, end=end_rev, args="--author-date-order"
+    start=start_rev, end=end_rev, args="--topo-order"
)

But I suppose this may be breaking to existing changelogs, so I wonder what is your take on this?

[sacha-c]

Any thoughts about the aftermentioned issue?

[woile]

We could introduce this to the v3 branch. Could you submit a PR pointing to the v3 branch? Thanks!

[sacha-c]

I can do that 👍 I just wanted to make sure this approach is the desired one

Because I also suppose that --author-date-order may have been used for a specific reason?

[woile]

The output of --author-date-order looked good when we tested it, because the default one was creating problems. I don't recall testing --topo-order, but I think if the tests pass we shouldn't have a problem. Worst case scenario, I think we can expose the ordering to users

[sacha-c]

@woile I've made a PR here, and am happy to receive feedback
Also curious, what is the roadmap for commitizen? Is there already an estimate for when v3 will be available?

[woile]

Sorry for the slow cadence. No proper roadmap, @Lee-W and me are with a short available capacity and I think in general commitizen meets our expectations, that's probably why development goes at this rate (which I also think is fine).
That being said, I'm looking forward to some new features coming soon, so I'd like to release v3 as soon as possible.

If I were to give a date, worst case scenario, I'll organize a sprint for europython 2023 in July and push for this change to commitizen. Because I'd like to review in depth v3 and verify things work. Hopefully before that

[sacha-c]

Okay! Thanks for the explanation and details about V3, makes sense.
Looking forward to it!