Skip to content

Commits got repeated when I format the CHANGELOG file manually? (revamp #133) #142

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JonathanLoscalzo opened this issue Apr 19, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@JonathanLoscalzo
Copy link

JonathanLoscalzo commented Apr 19, 2024

Describe the bug
I have wanted to edit the changelog manually, because I have a lot of all commits in the history that I don't want to preserve in the changelog.
During the edition, accidentally I have format the file with vscode and some blank spaces got removed.

When I bump the version again, the selected commits are not from "v0.0.X..v.0.0.Y", it selects it from the first commit again.

So, I assumed that if we modify the format of the changelog for whatever reason, it will fail.
Is there any possibility to pass two properties? like the range of commits to generate instead of read the changelog.

There are situation where we want to switch from a changelog generator to another, and I want to preserve all history. I mean, it could be possible to skip that check and just use last two "v-tags"?

Steps to reproduce:

npm init --yes
git init
echo "node_modules" > .gitignore
git add . 
git commit -m "feat: init"

for i in {1..5}; do
  git commit -m "feat($i): important feature $i" --allow-empty
done

for i in {1..5}; do
  git commit -m "fix($i): important feature $i" --allow-empty
done

npx --yes commit-and-tag-version --first-release

# modify the changelog JUST THE FORMAT
echo "{}" > .prettierrc
npx --yes prettier CHANGELOG.md --write
git add CHANGELOG.md 
git commit --amend --no-edit

# Create a commit between v1 and v2
git commit -m "feat(v2): important feature v2" --allow-empty


# If I release it, the unique commit that will be added to the changelog is the last one
npx commit-and-tag-version 

# CHECK CHANGELOG!

Current behavior

  • Changelog is generated from the beginning over and over

Expected behavior

  • Changelog should be generated from commits between vX -> vY, that is commits between last version and current one, and not from the beginning of the history.

Environment

  • commit-and-tag-version version(s): v12.20.0
  • Node/npm version: v20
  • OS: Ubuntu 22 (but it doesn't matter)

Possible Solution

  • Use something similar for listing commits like `git log $(git describe --abbrev=0 --tags)..HEAD``
  • expose a method to list the changelog output with versions as inputs or similar

Additional context

@JonathanLoscalzo JonathanLoscalzo added the bug Something isn't working label Apr 19, 2024
@trustyCappelletti
Copy link

Is there a workaround for this? Everytime I run release i have to make a clean up of the logs in the changelog

@trustyCappelletti
Copy link

trustyCappelletti commented Dec 28, 2024

Okay i found a workaround:

If you run:

git tag

You will notice that there are tags shown here that are not shown if your run

npx git-semver-tags

This is because for some reason when you run commit-and-tag-version, the tag that is being created is not recognized as a git-semver-tag (I havent made more research about this, I'm speculating that its happening because the tag is not properly annotated). In order for the changelog to be generated properly, the tags have to be recognized as semantic version tags.

So to fix this I ran git log and searched for the commit that should have the git tag (Its always the one that has chore(release): "v1.5.1" message) copied its hash, then deleted the tag running git tag -d "v1.5.1" and created it properly running:

git tag -a v1.5.1 commit_SHA -m 'chore(release): 1.5.1'

This creates a git tag that will be recognized when generating the changelog. You also might have to delete the remote tags and push them again in order for you to push the new corrected tags, you can delete the remote tags by running:

git push --delete origin v1.5.1

Also, because this is happening after formatting the changelog by hand, its likely to happen in the future again, so maybe you will have to go through this whole process for every release (only for the newly wrongly generated tag)

conventional-changelog#628 this was my source to figure all this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants