René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Inconsistent changelog behavior based on rev-range \u0026 merge strategy","articleBody":"### Description\r\n\r\nWe are running into inconsistent behavior of the changelog command depending on the rev-range used when we have a branch with different merge commits.\r\n\r\nThe reason is that when generating the changelog, commitizen is using the author-date-order ([see here](https://github.com/commitizen-tools/commitizen/blob/master/commitizen/commands/changelog.py#L147-L149))\r\n\r\nThis 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)\r\n\r\n### Steps to reproduce\r\n\r\nHere is an example (you can find this example in a test github repo [here](https://github.com/sacha-c/commitizen_changelog_bug_example):\r\n\r\n1. Create a main branch with an initial commit with commitizen setup \u0026 a `cz bump` commit v0.1.0\r\n2. Create mr 1 off of main \u0026 make a commit\r\n3. Create mr2 off of main \u0026 make a commit\r\n4. Merge mr1 into main with `git merge mr1`\r\n5. Run `cz bump` (tags v0.2.0)\r\n6. Merge mr2 into main with `git merge mr2`\r\n7. Run `cz bump` (tags v0.3.0)\r\n\r\nWe end up with the following git tree:\r\n```bash\r\n(venv) ***@*** commitizen_changelog_bug_example % git log --graph --oneline --all\r\n* a48e0e5 (HEAD -\u003e main, tag: v0.3.0, origin/main) bump: version 0.2.0 → 0.3.0\r\n*   d247ed7 Merge branch 'mr2'\r\n|\\  \r\n| * 36b659e (origin/mr2, mr2) feat: mr2\r\n* | 7b97d2c (tag: v0.2.0) bump: version 0.1.0 → 0.2.0\r\n* | 82f3844 (origin/mr1, mr1) feat: mr1\r\n|/  \r\n* 1162498 (tag: v0.1.0) bump: version 0.0.1 → 0.1.0\r\n* e76ef76 feat: initial commit\r\n```\r\n\r\nThe expectation now is for `cz changelog v0.3.0` \u0026 `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.\r\nHere is the output of the different commands\r\n\r\n```bash\r\n(venv) ***@*** commitizen_changelog_bug_example % cz changelog v0.3.0 --dry-run\r\n## v0.3.0 (2023-01-26)\r\n\r\n### Feat\r\n\r\n- mr2\r\n\r\n(venv) ***@*** commitizen_changelog_bug_example % cz changelog v0.2.0 --dry-run\r\n## v0.2.0 (2023-01-26)\r\n\r\n### Feat\r\n\r\n- mr1\r\n\r\n(venv) ***@*** commitizen_changelog_bug_example % cz changelog v0.2.0..v0.3.0 --dry-run\r\n## v0.3.0 (2023-01-26)\r\n\r\n## v0.2.0 (2023-01-26)\r\n\r\n### Feat\r\n\r\n- mr2\r\n- mr1\r\n```\r\n\r\n### Current behavior\r\n\r\nRunning `cz changelog v0.3.0` \u0026 `cz changelog v0.2.0..v0.3.0` gives a different output under the *v0.3.0* entry\r\n\r\n### Desired behavior\r\n\r\nRunning `cz changelog v0.3.0` \u0026 `cz changelog v0.2.0..v0.3.0` gives the same output under the *v0.3.0* entry\r\n\r\n### Screenshots\r\n\r\n_No response_\r\n\r\n### Environment\r\n\r\nCommitizen Version: 2.40.0\r\nPython Version: 3.10.9 (main, Dec 27 2022, 11:11:24) [Clang 14.0.0 (clang-1400.0.29.202)]\r\nOperating System: Darwin\r\n\r\n### Proposed solutions/ideas\r\nI *think* the solution would be to change\r\n```diff\r\ncommits = git.get_commits(\r\n-    start=start_rev, end=end_rev, args=\"--author-date-order\"\r\n+    start=start_rev, end=end_rev, args=\"--topo-order\"\r\n)\r\n```\r\n\r\nBut I suppose this may be breaking to existing changelogs, so I wonder what is your take on this?","author":{"url":"https://github.com/sacha-c","@type":"Person","name":"sacha-c"},"datePublished":"2023-01-26T09:52:42.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/660/commitizen/issues/660"}