You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support branches often have tags that do not get merged back to the master/trunk. If one of these tags is older than the most recent tag on the current branch things break.
Steps to Reproduce
mkdir repo; cd repo; git init
for i in 0 2 10; do touch file$i; git add file$i; git commit -m "commit $i"; git tag v1.$i.0; done
git branch support; git checkout support
for i in 11; do touch file$i; git add file$i; git commit -m "commit $i"; git tag v1.$i.0; done
git checkout master
for i in 20; do touch file$i; git add file$i; git commit -m "commit $i"; git tag v1.$i.0; done
Then
~/chglog/chglog init; ~/chglog/chglog format -t rep
Commit 1.11.0 is from the support branch so when walking the commits from 1.20.0 back to the previous version it ends up walking all the way back to the first commit.
The following from init.go looks like it is trying to protect against this:
if commitObject, err = gitRepo.CommitObject(start); err != nil {
// This ignores objects that are off branch which happens when tagging on multiple branches happens.
if errors.Is(err, plumbing.ErrObjectNotFound) {
continue
}
return nil, fmt.Errorf("unable to fetch commit from tag %v: %w", tagName, err)
}
But that is checking if the commit is not in the repo, it is, just on a different branch.
Possible Fix
Walk the Log once with a map of all the tags, and toss out any tags that don't have any commits. Use this as a semver sorted list that we iterate over.
I've got a solution coded up as both a test and fix. I was thinking of first doing a pull request of just the test to document this better. And then add the potential fix.
The text was updated successfully, but these errors were encountered:
Summary
Support branches often have tags that do not get merged back to the master/trunk. If one of these tags is older than the most recent tag on the current branch things break.
Steps to Reproduce
Then
Produces
Commit
1.11.0
is from thesupport
branch so when walking the commits from1.20.0
back to the previous version it ends up walking all the way back to the first commit.The following from
init.go
looks like it is trying to protect against this:But that is checking if the commit is not in the repo, it is, just on a different branch.
Possible Fix
Walk the Log once with a map of all the tags, and toss out any tags that don't have any commits. Use this as a semver sorted list that we iterate over.
Doing this would produce:
Code
I've got a solution coded up as both a test and fix. I was thinking of first doing a pull request of just the test to document this better. And then add the potential fix.
The text was updated successfully, but these errors were encountered: