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
Let's suppose we have a monorepo with two projects and the following structure:
.github/
project-foo/
project-bar/
README.md
Releases are tagged foo-vX.Y.Z and bar-vX.Y.Z for the two projects.
Let us suppose, for this scenario, that I just made some changes to the way the packages are released in .github/ and I release new version of bar, tagging that commit that only modifies files within .github/.
Problem
It would appear that Git Cliff filters commits first and then looks for release tags within these commits.
The problem here is that by filtering commits first and listing tags from the resulting subset, the commit (and therefore associated tag) in the scenario above also gets removed.
While it is correct to filter out the commit from the changelog for bar since it doesn't touch any files within project-bar/, I would say that it is incorrect for Git Cliff to be filtering the tags as well.
Solution
I'm not familiar with Git Cliff's internals, but I think Git Cliff needs to:
Match the release tags irrespective of the associated commit's changes; and then,
Generate the changelog from the subset of commits that match the include/exclude paths, with the tags from (1) merely providing labels to help group the commits.
Expected behavior
The version tag is correctly picked up, even if the associated commit does not touch any files within the path filters.
@orhun, yes I'll work on this in the evening. I reckon we don't really have to care about path filters etc. Instead I would change the commit processing, such that ignored commits aren't dropped outright. They need to be kept until all of the release tags have been found and processed.
Background
Let's suppose we have a monorepo with two projects and the following structure:
Releases are tagged
foo-vX.Y.Z
andbar-vX.Y.Z
for the two projects.Let us suppose, for this scenario, that I just made some changes to the way the packages are released in
.github/
and I release new version ofbar
, tagging that commit that only modifies files within.github/
.Problem
It would appear that Git Cliff filters commits first and then looks for release tags within these commits.
The problem here is that by filtering commits first and listing tags from the resulting subset, the commit (and therefore associated tag) in the scenario above also gets removed.
While it is correct to filter out the commit from the changelog for
bar
since it doesn't touch any files withinproject-bar/
, I would say that it is incorrect for Git Cliff to be filtering the tags as well.Solution
I'm not familiar with Git Cliff's internals, but I think Git Cliff needs to:
Expected behavior
The version tag is correctly picked up, even if the associated commit does not touch any files within the path filters.
Software information
Darwin 24.3.0
(macOS 15.3)Additional context
See this Discord thread
The text was updated successfully, but these errors were encountered: