Question: Wrong ordering when using feature -> development -> master branch

[Maartendohmen]

Hi there,

I have the following question concerning the generation of the release logs. I'm using the current branch strategy:

Feature branch: To develop individual features for my application.
Development branch: When a feature is ready, it is merged to this branch.
Master branch: Once in a while, I merge the development to this branch, creating a release (and also generating the release notes)

When generating the release notes, it sometimes moves all commits from one version to a later one (see for example empty 1.48.0 , where all features for that version are bumped a version and are in 1.48.1)
.

The release structure looks like this in git, where the blue line is the master branch, and the red and yellow lines are the develop branch, being merged into the master.

Am I doing anything wrong with the merging or is multiple branches like I have not supported? Looking forward to your response, thanks in advance!

Kind regards
Maarten

[tomasbjerre]

How do you use the library? How exactly did you configure it?

[Maartendohmen]

I normally use it with the maven plugin (https://github.com/tomasbjerre/git-changelog-maven-plugin). I also ran it locally using the command line tool, so I could debug it a bit myself, this produces the same issue.

The arguments I use are:
-of test.html
-df "dd / MMM / yyyy"
-t path/to/template
--show-debug-info
-js jiraurl
-ju jira-username
-jpw jira-password
-jp "SPARK-([0-9]+)"
--repo path/to/git
-je

While debugging I noticed that it's populating the tags in populateComitPerTag(). But for some reason it also puts the commit belonging to a previous tag in to the later one.

[tomasbjerre]

It would help if it can be repeated in an open Git repository.

[tomasbjerre]

I created a copy of your history and I can repeat this now.

[Maartendohmen]

I tried to re-create it myself today but did not manage to do it (in time atleast 😄) . Any idea what could be wrong? I think it has something todo with the way I merge back and from development branch to master. It looks like it skips over the tag in the history.

[tomasbjerre]

* bf1ce04 - (HEAD -> master, tag: 1.48.1) work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
*   1c38289 - Merge branch 'b6' (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\  
| * a78a261 - (b6) work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 7dc02cd - work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 585a490 - work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 6947646 - work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 7d5b434 - work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * a0f156e - work (3 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|/  
*   c45fb15 - Merge branch 'b5' (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\  
| * 16040fc - (b5) work (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 603bf46 - work (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 5d66d6a - work (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|/  
*   8972f0b - Merge branch 'b4' (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\  
| * 30db56a - (b4) work (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 624047b - (tag: 1.48.0) work (4 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|/  
*   efb0944 - Merge branch 'b2' (5 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\  
| * afd5534 - (b2) work (5 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 715bbd7 - work (5 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * 69f0f4d - work (5 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| *   51f6cd7 - Merge branch 'master' into b2 (6 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| |\  
| |/  
|/|   
* |   5f618fe - Merge branch 'b3' (7 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\ \  
| * | 3263094 - (b3) work (8 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| * | e28f3f2 - work (8 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| | * 840b8a9 - work (8 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
| |/  
|/|   
* |   eee58bc - Merge branch 'b1' (9 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|\ \  
| |/  
|/|   
| * 5396891 - (b1) work (9 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
|/  
* 81069a1 - work (10 minuter sedan) <Tomas Bjerre><Tomas Bjerre>
* 623a078 - work (10 minuter sedan) <Tomas Bjerre><Tomas Bjerre>

The question here is what tag should efb0944 belong to. If tag: 1.48.0 was on master it would be obvious, but now efb0944 is a child of both 1.48.0 and 1.48.1.

[Maartendohmen]

I would like to prevent that in if that's possible (perhaps with a different strategy?). In this case, I would want to merge master back to development (8972f0b) and make sure that development also has the commit with the tag in it. I guess then it should stop and not skip over it.

To answer your question, in this case I would want all my changes that I merge from development to master (efb0944),so all the commits before the release, to be in tag 1.48.0, not 1.48.1

[tomasbjerre]

I have been fiddling with this and came up with 2 possible solutions

• Parse all parens of a commit first, until a merge commit is found: https://github.com/tomasbjerre/git-changelog-lib/compare/feature/issue-147?expand=1
• Parse most recent commits first: https://github.com/tomasbjerre/git-changelog-lib/compare/feature/issue-147-prio?expand=1

[Maartendohmen]

Awesome, thanks for the quick responses and work, really appreciate it! I tried both solutions locally:

The one where you check for merge commits definitely improves it, but it is still not 100% getting all release note correct. In the image below I marked 2 merge commits, which should be under 1.43.0, but are still indexed under 1.44.0

The second solution, parsing them in order of most recent commits, does work correct. In that case all release notes are under the correct tag!

[tomasbjerre]

I released the second solution now. Thanks for reporting!