I first reported this in the gitter chat (see thread). Now opening an issue so that the problem can be properly addressed.

background

Users can set the --base parameter to migrate from an old changelog to github-changelog-generator ... asking github-changelog-generator to append the "old" changelog (i.e., the "base) to the new, automatically generated changelog.

Crucially, github-changelog-generator assumes that the old changelog contains proper versions and that each of those versions in the old changelog corresponds to a tag in the GitHub repo.

This assumptation was probably intended as a nice feature to (i) parse the old changelog for all versions, (ii) take the most recent "old" version, and (iii) use that version as the automatic input into the --since parameter.

See the code implementation:

https://github.com/github-changelog-generator/github-changelog-generator/blob/8b03a1192b15bf1a65062c926ea8d37b8253d34c/lib/github_changelog_generator/generator/generator_tags.rb#L100-L114

problem

Unfortunately, this becomes problematic once the implicit assumption is not fulfilled.

For example, when an old changelog's versions do not correspond with the tags in the git history (which is entirely possible, strange things happen during migration ... and sometimes people migrate from one platform to another or to another version control system altogether).

The problem surfaced only recently, with https://github.com/github-changelog-generator/github-changelog-generator/pull/621 introducing an error when a tag specified with --since could not be found.

solution

I think this issue could be reasonably solved by allowed to explicitly set --since-tag to some "None" or "Null" value ... and thus preventing an automatic overriding of it if --base is specified.

Alternatively, it would help us if we could specify a "commit" instead of a tag for --since-tag. Then we would just put the first commit in our repo for --since-tag and it wouldn't get overridden when we specify --base.