jenkinsci/git-changelog-plugin

commit order

Closed this issue · 4 comments

Jenkins and plugins versions report

.

What Operating System are you using (both controller, and any agents involved in the problem)?

.

Reproduction steps

I apologize for the bad wording. But it's a question I had asked on stackoverflow a long time ago and I don't know if it's a bug or not.

I hope that someone who understands git and gitchangelog knows what I mean and can clarify what is happening.

I'm using git changelog in jenkins to serve up a sort of document with a change log. The tags are in the master branch, we modify master with merge request only, and the operation is as follows

  1. get the last tag
  2. create new tag
  3. generate changelog between the two tags.

I am trying to release a version of a feature_branch to be tested in test environments

I have applied the same process, but it generated a lot of changes and these were in previous versions.
If I look at the web version of bitbucket it confirms:
enter image description here

Between the tag generated in the feature_branch and the last version released there are only 2 commits and a merge

On the other hand, if I switch to the feature_branch and look at the git log I can see all the commits out of order (the tag of the previous version is lower than what the web version shows), and this would justify why gitchangelog didn't work as expected.

On the other hand if I do git log --oneline I see the commits in the same order as the web version. I understand that it is the expected order. Gitk also displays them in a "tidy" way

What's going on here? how are git commits ordered between branches?

How can I fix it and have the commits appear in the correct order?

How to work with different branches and preserve the order of the commits? how to avoid these problems?

Expected Results

.

Actual Results

.

Anything else?

.

I think that sort commits by commitTime can be a mistake when generating the changelog for many workflows that works with pull request.

In fact, I think that the only case that would work correctly is when the merge reques allow squash merging.

In the case of merge commit, it would be useful to be able to build the log based only on the first parent
git log --first-parent

After some research, to get the commits between versions I ended up using git log --pretty=oneline --topo-order --ancestry-path tagStart..tagEnd

More detail in https://stackoverflow.com/a/72374838/1989579