@olleolleolle, of course:

$ github_changelog_generator -v
Version: 1.14.3

$ gem i github_changelog_generator --pre
Fetching: retriable-3.1.1.gem (100%)
Successfully installed retriable-3.1.1
Fetching: github_changelog_generator-1.15.0.pre.beta.gem (100%)
Successfully installed github_changelog_generator-1.15.0.pre.beta
2 gems installed

$ github_changelog_generator -u AlexWayfer -p flame

Almost the same (just duplicate about #7 removed from enhancements):

- Fix `flame` gem in template Gemfile [\#34](https://github.com/AlexWayfer/flame/pull/34) ([AlexWayfer](https://github.com/AlexWayfer))
- Add `Flame::Application.require\_dirs` method [\#33](https://github.com/AlexWayfer/flame/pull/33) ([AlexWayfer](https://github.com/AlexWayfer))
- Remove patch-versions of Ruby for Travis CI [\#32](https://github.com/AlexWayfer/flame/pull/32) ([AlexWayfer](https://github.com/AlexWayfer))

## [v4.18.1](https://github.com/AlexWayfer/flame/tree/v4.18.1) (2017-07-29)

[Full Changelog](https://github.com/AlexWayfer/flame/compare/v4.18.0...v4.18.1)

**Implemented enhancements:**

- Add `version` option for `Controller\#url\_to` method with static files [\#14](https://github.com/AlexWayfer/flame/issues/14)
- Raise error if no file for rendering [\#12](https://github.com/AlexWayfer/flame/issues/12)
- Change routing system [\#3](https://github.com/AlexWayfer/flame/issues/3)
- Replace Array-based routes system with Hash-based [\#27](https://github.com/AlexWayfer/flame/pull/27) ([AlexWayfer](https://github.com/AlexWayfer))

**Fixed bugs:**

- Don't allow change the order of optional parameters in path [\#7](https://github.com/AlexWayfer/flame/issues/7)

## [v4.18.0](https://github.com/AlexWayfer/flame/tree/v4.18.0) (2017-06-27)

(I'm sorry for terseness before. There is no excuse for that.)

The decision on which tag to put "Issues and PRs" into is done using the merged_at timestamp, if I recall correctly.

Code search for that: https://github.com/skywinder/github-changelog-generator/search?utf8=%E2%9C%93&q=merged_at&type=

There's been previous reports of issues with this, especially when you run maintenance and release branches.

This is an "area under scrutiny", and test-cases, reproduce scripts, or input is very welcome.

Thank you for reporting this.

This is an "area under scrutiny", and test-cases, reproduce scripts, or input is very welcome.

I understand that this program is based on time (merged_at or created_at), and this is an iron condition in its principle of operation, but I'm talking about the problems that accompany this decision.

How to reproduce, I guess:

• master branch with commit at 17:00, for example
• feature-branch (in PR, open) with commit at 18:00
• new commit (version update, for example) in master at 21:00
• Merge PR, but with rebase

Commit from feature-branch will be after release-commit in master, but with earlier date.

And I don't sure that merged_at is correct for rebased commits from PRs.

Suggestions:

1. Maybe this program should be based on line-history of commits, ignoring its date-times.
2. Maybe basing on tags will be simpler for realization. This commit has no tags, as well as further commits. Last commit with tag — commit with version update, before rebased feature-commit.

I'm running into the exact same issue with github_changelog_generator 1.14.3. In my friends gem commit list I just added commit ed54d60 (new rebased version: f49cb49) as the only change in version 0.35 of my gem. However, because I guess I started working on that change before version 0.34 was released and I rebased before merging, my changelog now has the merge commit appearing in 0.35 (correctly) and the actual code commit appearing in 0.34 (which is incorrect).

I tried overwriting the git history with git-redate to change the date of commit ed54d60 to reflect when I actually pushed it (this changed the commit hash to f49cb49), but that didn't work because the GitHub Issue for the feature still thinks it was closed in ed54d60 which github_changelog_generator still thinks is part of version 0.34.

I then tried manually reopening and re-closing the issue, but now github_changelog_generator thinks it's an unreleased change that is not a part of 0.35.

In the end I had to remove and re-add the tag, doing a lot of rewriting of the git history, to get it to appear as expected. I think either of @AlexWayfer's two suggestions would have solved this problem for me.

@AlexWayfer There appears to be something amiss...

• The commit that you point out occurs directly following the v4.18.1 tag (AlexWayfer/flame@e34118f) does not appear to be related to any pull requests according to github's api (https://api.github.com/repos/AlexWayfer/flame/commits/e34118f). That commit may have been pushed to the repository outside of Github's pull request system?
• It appears that https://api.github.com/repos/AlexWayfer/flame/commits/e34118f is a rebase of https://api.github.com/repos/AlexWayfer/flame/commits/d2a3f17
• https://api.github.com/repos/AlexWayfer/flame/commits/d2a3f17 appears to be the merge_commit_sha in https://api.github.com/repos/AlexWayfer/flame/pulls/27 so is the real commit of Replace Array-based routes system with Hash-based AlexWayfer/flame#27 according to githubs api.
• The events for Replace Array-based routes system with Hash-based AlexWayfer/flame#27 via the api https://api.github.com/repos/AlexWayfer/flame/issues/27/events do not list e34118f anywhere, only https://api.github.com/repos/AlexWayfer/flame/commits/d2a3f17 as the merge event, confirming this.
• Doing a git clone does not fetch d2a3f17 and so GCG has no idea where in the changelog to put Replace Array-based routes system with Hash-based AlexWayfer/flame#27

So I conclude that some local git rebasing killed the commit SHAs related to the various github pull requests and were overwritten by a force push to master. There's not much github-changelog-generator can do when the git history doesn't match github's api.

Sorry.

@JacobEvelyn Yours looks similar; https://api.github.com/repos/JacobEvelyn/friends/pulls/187 merge_commit_sha is https://api.github.com/repos/JacobEvelyn/friends/commits/a337549 and merged ed54d90. Your git-redate changed the git SHA and decoupled it from the api PR history.

The first suggestion to base changes on git history rather than merge times is implemented in #619 and may work better for you.

@hunner, thank you. That's strange. I really rarely use force push to master. But maybe something went wrong…

It appears that https://api.github.com/repos/AlexWayfer/flame/commits/e34118f is a rebase of https://api.github.com/repos/AlexWayfer/flame/commits/d2a3f17

Can this be checked by github-changelog-generator? Via GitHub API or git. But I see:

Doing a git clone does not fetch d2a3f17 and so GCG has no idea where in the changelog to put AlexWayfer/flame#27

, and I think the answer is "no".

It's very sad.

Sorry if this commit's mess was my fault.

@AlexWayfer @JacobEvelyn I added a "rebased commit: " ability to #619 to be able to track PRs that are merged with modified SHAs with GCG \o/

@hunner, thank you! 👏

Merged. I've used it a surprising amount of times. Sometimes the github API just loses track of merge commits of older PRs too. I don't know why.

👋🏻 there still appears to be issues where the diffs generated are non-deterministic 🤔

It looks like from the last comment (from over two years ago) that this is caused by the GitHub API rather than a code/logic bug. Is there a reason this issue hasn't been bubbled back up to GitHub and the repo/team responsible for their API layer?

Thanks!

@Integralist If you have a way to let them know about it, please feel free to direct their attention to this problem (and this Issue in this repo). There's no other reason than nobody doing it.