Locally generated changelog isn't including the diff link in version headings

[kleinfreund]

Describe the bug

When running npx commit-and-tag-version locally, I find that changelog generation works differently from the exact same command execution in CI.

Specifically, the version headings don't include the diff link when running locally. As a result, the command duplicates the entire changelog and adds the new entry to the top.

Notably, the content under each version heading is the same as before including the commit hash links in parentheses so it's only the headings that are different.

npx commit-and-tag-version --release-as patch:

✔ bumping version in package.json from 16.0.0 to 16.0.1
✔ bumping version in package-lock.json from 16.0.0 to 16.0.1
✔ outputting changes to CHANGELOG.md
✔ committing package-lock.json and package.json and CHANGELOG.md
✔ tagging release 16.0.1
ℹ Run `git push --follow-tags origin main && npm publish` to publish

Current behavior

Version headings don't include links to the diff view in GitHub.

## 16.0.1 (2025-08-05)

Expected behavior

Version headings do include links to the diff view in GitHub.

## [16.0.1](https://github.com/ORG/REPO/compare/v16.0.0...v16.0.1) (2025-08-05)

Environment

• commit-and-tag-version version(s): 12.5.2
• Node/npm version: v23.11.1/11.5.2
• OS: macOS 15.6

Possible Solution

I reckon the version headings being different causes the duplication of virtually the entire changelog because some internal logic checks the diff between old and new changelog (this is conjecture; I haven't looked at the source code).

Additional context

• The last time a version in my software was published was on commit-and-tag-version using version 12.5.1 on 2025-07-23 via CI workflow and it generated the changelog as expected. This indicates that this is not a regression since 12.5.1 as 12.5.2 contains only one change that is certainly unrelated.

[TimothyJones]

I can’t reproduce this, I’m afraid. I suspect there is some difference in your setup locally.

Do you have the tags downloaded in your local clone? If they’re missing, it might cause this.

[kleinfreund]

Huh, strange.

• I have all tags in the local clone (git tag -l shows them all, git fetch --tags didn't pull any new ones)
• The branch I work on is main and reset to the remote branch's state
• I only added git commit --allow-empty -m "fix: test release" to test the release procedure
• The command I ran matches that which is run in the CI workflow exactly: commit-and-tag-version --release-as patch
• There's no commit-and-tag-version config object in the package.json file or a .versionrc, .versionrc.json or .versionrc.js file
• The transitive dependency conventional-changelog is installed as v4.0.0 (so despite outdated, it's what this package depends on) and is not being overridden

Now, the release procedure is exclusively run in CI and so doing this locally is rare and likely only done for testing purposes. That means that this could be an issue for a long time. I doubt it would occur in the CI workflow and so it must be a difference in the local clone and setup compared to the CI one.

But I'm stumped, I don't have any clues to explain this. If I have some time, I'll look into the related conventional-changelog code.

---

Logging the options object of the conventional changelog writer, the headerPartial looks correct:

## {{#if @root.linkCompare~}}\n
  [{{version}}]({{~@root.host}}/{{#if this.owner}}{{~this.owner}}{{else}}{{~@root.owner}}{{/if}}/{{#if this.repository}}{{~this.repository}}{{else}}{{~@root.repository}}{{/if}}/compare/{{previousTag}}...{{currentTag}})\n
{{~else}}\n
  {{~version}}\n
{{~/if}}\n
{{~#if title}} "{{title}}"\n
{{~/if}}\n
{{~#if date}} ({{date}})\n
{{/if}}\n

Digging further, I think the culprit is here:

In lib/merge-config.js of conventional-changelog-core, the gitSemverTags array on line 151 remains empty and that leads to @root.linkCompare not being true in the template engine.

Further down the rabbit hole, it's ultimately the git-semver-tags package that doesn't yield any tags in its result.

[kleinfreund]

And I found the root cause. Annoyingly/embarrassingly I ran into this exact issue before.

TL;DR: my git config contains a setting for format.pretty:

[format]
	pretty = format:%C(yellow)commit %H%nAuthor: %an <%ae>%nDate:   %ad%n%n%C(green)%B

which ends up breaking git-semver-tags parsing. This could be fixed in git-semver-tags (or perhaps this wouldn't happen with a more recent version) but on my end, I can only fix it by changing my git config:

  [format]
- 	pretty = format:%C(yellow)commit %H%nAuthor: %an <%ae>%nDate:   %ad%n%n%C(green)%B
+ 	pretty = format:%C(yellow)commit %H%d%nAuthor: %an <%ae>%nDate:   %ad%n%n%C(green)%B
  #                                    ^^ adds ` (tag: v16.0.1)`

[TimothyJones]

Ah, that’s frustrating (good find, though!)

We’re using an outdated version of the conventional changelog dependencies- I need to find the time to migrate this to ESM so we can pick up the latest.

[TimothyJones]

Potentially we can work around it by passing got different config?

[kleinfreund]

Potentially we can work around it by passing got different config?

I don't think this can be worked around on the side of this package by passing in a different config as you won't be able to influence the command that is spawned in git-semver-tags.

You could in theory patch the distributed code in git-semver-tags in that one line that contains the git log command to definitely avoid the problem:

node_modules/git-semver-tags/index.js:7:

- const cmd = 'git log --decorate --no-color'
+ const cmd = 'git log --decorate --no-color --pretty=medium'

But it seems like a fairly niche edge case. Now that this issue exists, people hopefully find it and can avoid it similarly to what I did.

That being said, eventually getting this package to use more up-to-date versions of the conventional-changelog world would of course be great. But as I understand it, there have been quite a lot of structural changes there that aren't trivial to integrate.

[TimothyJones]

Re: this issue - What would could do is check the git settings, and emit a helpful error or warning if the format is non standard.

Re: ESM migration - yeah, we’ve had a few volunteers over the years, but unfortunately it needs more focussed attention than is likely (or perhaps reasonable) for a first time contributor.

The main challenge is the mocking of the file system and git state - if you don’t get that right in the migration, then the tests stamp all over the repo.

I tried to get AI to do it in a spare hour a few weeks ago, but it struggled with this- you can’t just modify the tests and see if they work. It needs several hours of human effort I think