Why are there duplicate records on different versions

[alanhe421]

Why are there duplicate records on different versions. I am very confused, has anyone encountered the same problem?

[tommywo]

This might be this conventional-changelog/conventional-changelog#567
Can you try uninstalling and installing standard-version?

[alanhe421]

@tommywo The version number has not changed？

[mihaisavezi]

This is exactly conventional-changelog/conventional-changelog#567.

Happens for me on 7.1.0 and on 4.3.0.

[jacktan165]

Same for me in 7.1.0. I downgraded to 7.0.1 and 7.0.0, but it is still happening.
Did anyone solve this issue?

[GlennM]

Having same issue: new entries are added to the changelog, but old ones getting re-added as well to the new version.

• "standard-version": "^7.1.0"
• Using yarn release

[jacktan165]

I realized I need to do git push origin master instead of git push to fix it. Did you try this?

[btkfrank]

I realized I need to do git push origin master instead of git push to fix it. Did you try this?

can you elaborate this?
What I see is the change log is always comparing a specific tag to the latest tag, and hence it generates duplicate record

[GlennM]

Having same issue: new entries are added to the changelog, but old ones getting re-added as well to the new version.

• "standard-version": "^7.1.0"
• Using yarn release

It turned out that my git process was not fully correct (thanks StackOverflow).
I don't have any issues with this package anymore :)

[robaxelsen]

I am still having this issue. Upgraded to vs 8.0.0, which should have the fix referenced by @tommywo in conventional-changelog/conventional-changelog#567.

[ldanielw1]

Also having this issue in v8.0.0. But I've noticed that it has to do with architecture too...? it works on my mac but not on my jenkins CI's debian build executor...

[petertwise]

I was experiencing this and caught it too late - my changelog was hopelessly messed up with lots of duplicates. I found the issue had to do with failing to tag each release correctly as @btkfrank said. A quick way to confirm this is to see if you have something like ## [1.2.3](https://github.com/myuser/myrepo/compare/v1.0.0...v1.2.3) - looks like your last tag was v1.0.0 and that's what it's using to compare to your new release of v1.2.3 in this example. But it probably already also made a changelog comparing v1.0.0 to v1.1.0; v1.0.0 to v1.1.1; v.1.0.0 to v1.2.0; etc. Yikes!

I resolved it without a painful manual fix of the changelog by doing this:

1. checkout the commit that has the last actually applied tag (example: git checkout v1.0.0) and double check that your changelog looks good
2. directly checkout the commit that was the next commit that should have been tagged (example: git checkout 123acb123blahthisisthefullhash123456)
3. do a dry run so the console will spit out what the automatically generated changelog should have been npm run release -- --release-as 1.1.0 --dry-run - copy and paste that bit of changelog into a fresh temporary text file somewhere outside your repo.
4. now that you are on the commit that should have been tagged - tag it. (example: git tag v1.1.0)
5. if there are more commits that didn't get tagged, go back to step 2 and repeat until you are caught up. You must always only move one version number forward in time for this to work.
6. once you are finally back to your current HEAD, fix your changelog with accurate info in the external text file you've been using.
7. Commit your changelog fix and run the release again and make sure it gets tagged properly.

Phew!

[ldanielw1]

My issue is, unfortunately, a bit different. In my changelog, I don't even see any links - I get this:

### 0.0.62 (2020-08-13)

and everything to date is included in that new entry.

I also notice that it works fine on my mac, but when I'm doing this in a Jenkins docker build agent - this is what I get. Any hints at what might be happening?

[DuncanFaulkner]

I'm using standard-version 9.0.0 and I'm still getting duplicated change log messages, even though I'm doing a --follow-tags on git push.

[AThiyagarajan]

My issue is, unfortunately, a bit different. In my changelog, I don't even see any links - I get this:

### 0.0.62 (2020-08-13)

and everything to date is included in that new entry.

I also notice that it works fine on my mac, but when I'm doing this in a Jenkins docker build agent - this is what I get. Any hints at what might be happening?

Using version 9.0.0

I am also having the similar issue. When I run in my local (Mac), everything seems to be correct.
But when it run on the Jenkins, the heading are coming without any links.

[ldanielw1]

I just realized what happened on my Jenkins - it had been doing a git clone of only the branch that I was building - and so other tags didn't exist locally. I had to adjust my code to run a git fetch --all before running standard-version in order to get things working.

[AThiyagarajan]

I just realized what happened on my Jenkins - it had been doing a git clone of only the branch that I was building - and so other tags didn't exist locally. I had to adjust my code to run a git fetch --all before running standard-version in order to get things working.

I do figured out that it was Jenkins configuration issue.
My Jenkins pipeline is a multi-branch pipeline. For multi-branch pipeline by default checkout scm will not fetch tags.

To fetch the tags, I had to modify the Advance Cloning Options and check Fetch tags option.

After that it worked as expected.

[kunsinha79]

Has this issue been fixed?
I am using standard-version: ^8.0.0 and am facing the issue of duplicate commit logs in changeLog

[ldanielw1]

Has this issue been fixed?
I am using standard-version: ^8.0.0 and am facing the issue of duplicate commit logs in changeLog

Yes - if you're on Jenkins, you just need to adjust your git clone to actually fetch all tags. (if you're in a jenkinsfile, i'm not sure a clean way to do it beyond adding a sh 'git fetch --all' into your jenkinsfile

[Gratouille]

I just installed the whole commitlint + husky + standard-version "package" and I'm stuck in this issue. I have my commits repeated in my changelog and it's bad that the first reason (=> generating a proper changelog) to add this package won't even work properly :-(

What I did in order to make a proper changelog from the beginning, as explained here by @lukaszmn :

• changed the 193th line of the node_modules/conventional-changelog-core/lib/merge-config.js file from fromTag = gitSemverTags[options.releaseCount - 1] to fromTag = gitSemverTags[gitSemverTags.length - 1]
• removed the existing CHANGELOG.md file
• run the standard-version script (release, or just npx standard-version --skip.bump --skip.commit --skip.tag in order to test the changelog generation)

And, well, I don't know if this can help to fix this opened issue, but at least, by doing this in my projects, I get a proper changelog (I even added the v0.0.0 tag (which he talks about at the end of his website), at my "wanted-to-be" first commit in order to decide whenever to start the changelog).

Thanks to him, I'm no more stucked into this 👍

[bgrand-ch]

Same problem, my generate changelog repeat all previous commits and add new ones 🤔

[Tymek]

Thank you @ldanielw1 , git fetch --all in GitLab CI did the trick for me. 👍🏻

[christian-hawk]

2 years later... also happening with my projects.

[arvindanta]

@christian-hawk Did u find any solution for this ?

[christian-hawk]

@christian-hawk Did u find any solution for this ?

@arvindanta tagging the commit locally and re-running. Similar to what @petertwise posted.

[felicioandre]

Here, we resolved the problem by adding the configuration "tagPrefix": "". We don't use the character "v" before the tag version, it's just the number, e.g. 1.1.0.

This issue response helped us to resolve here.

[adnan-razzaq]

conventional changelog needs git tags to compare between what changed.
I am using release-it package for chnagelog generation.
Normally when I do release-it without crearting a tag it will generate changelog including the commits form previous release.
But if I had a tag it will only include new commits in changelog.