feat(parser): add bump and include_in_changelog flags

[arimu1]

Description

Adds two orthogonal optional fields on commit_parsers:

• bump = false — keep the commit in the changelog, exclude it from version bump calculation
• include_in_changelog = false — keep the commit for bump / filter_commits matching, omit it from changelog rendering

skip = true remains a hard drop. Defaults preserve existing behavior (both include when unset).

Motivation and Context

Fixes #1579 (follow-up to the discussion in #1564 / #1520).

With filter_commits = true and only feat/fix parsers, a release that only has docs commits currently reports nothing to bump. Matching docs with include_in_changelog = false lets bump see those commits while keeping them out of the changelog.

This matches the two-flag design suggested in the issue discussion.

How Has This Been Tested?

• cargo test -p git-cliff-core parse_commit_inclusion_flags
• cargo test -p git-cliff-core (70 passed; 1 unrelated failure: repo::test::git_upstream_remote when the feature branch has no upstream tracking remote configured)
• cargo +nightly fmt -p git-cliff-core -- --check
• Platform: macOS aarch64, Rust stable + nightly rustfmt

Example config:

commit_parsers = [
  { message = "^feat", group = "Features" },
  { message = "^fix", group = "Bug Fixes" },
  { message = "^docs", include_in_changelog = false },
]
filter_commits = true

Screenshots / Logs (if applicable)

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (no code change)
• Refactor (refactoring production code)
• Other

Checklist:

• My code follows the code style of this project.
• I have updated the documentation accordingly (if applicable).
• I have formatted the code with rustfmt.
  • cargo +nightly fmt --all
• I checked the lints with clippy.
  • cargo clippy --tests --verbose -- -D warnings (pre-existing clippy failures on main in changelog.rs remotes progress-message branch; not introduced by this PR)
• I have added tests to cover my changes.
• All new and existing tests passed.
  • cargo test

Made with Cursor

[orhun]

Hey, have you tested this locally? I'm not sure what's the different between skip and include_in_changelog options btw

[arimu1]

Yes, tested locally, on a throwaway repo. Config:

[git]
conventional_commits = true
filter_unconventional = true
tag_pattern = "v[0-9]*"

commit_parsers = [
  { message = "^feat", group = "Features" },
  { message = "^fix", group = "Bug Fixes" },
  { message = "^chore", group = "Chores" },
  { message = "^docs", group = "Documentation", include_in_changelog = false },
]

Repo: tagged v0.1.0, then two commits — feat: another feature after tag and docs: update usage section.

git-cliff --unreleased:

### Features
- another feature after tag

- statistics.commit_count = 2

The docs commit is gone from the rendered output, but statistics.commit_count is still 2 — it's not removed from the release, just hidden from the changelog body. --bumped-version is unaffected (v0.2.0, driven by the feat commit either way).

On skip = true for the same docs commit, statistics.commit_count drops to 1 — the commit is dropped from the release entirely, not just the changelog rendering. That's the actual difference: skip removes a commit from the pipeline (changelog, statistics, and bump, all at once, unconditionally). include_in_changelog and bump let you keep the commit in the release but exclude it from one of those two specific outputs, independently.

Concretely, something skip can't do today: keep a feat commit visible in the changelog but stop it from triggering a minor bump. Same config, bump = false on the feat parser instead:

### Features
- another feature after tag

- statistics.commit_count = 1

--bumped-version → v0.1.0 with a "next version is the same as the current version" warning, instead of v0.2.0. The commit is still fully present in the changelog and statistics, just excluded from the bump calculation. There's no way to get that with skip — skip would also erase it from the changelog.

So include_in_changelog = false and bump = false are inverses of each other (hide from changelog / keep in bump, vs. hide from bump / keep in changelog), and both are strictly weaker than skip, which removes the commit everywhere at once. I don't think they're redundant with skip, but happy to rename include_in_changelog to something less similar-sounding if that's the concern (e.g. changelog to mirror bump).

Also ran the full test suite (cargo test --workspace), including the new parse_commit_inclusion_flags test — all pass. The two red CI checks (Lints / Test suite) are pre-existing: Lints fails on the same clippy::useless_borrows_in_formatting in repo.rs:621 on current main (untouched by this PR), and Test suite's only failure is the Codecov CLI step (gpg: Can't check signature: No public key) — all actual Rust tests in that job pass. Confirmed both are red on main too.

[arimu1]

@orhun thanks — yes, the parser/config paths were exercised via the git-cliff-core integration tests in this PR (bump + include_in_changelog fixtures).

skip vs include_in_changelog

They operate at different layers:

• skip (commit parser / CommitParserConfig) — drops the commit from processing entirely (never becomes a changelog entry). Existing behavior.
• include_in_changelog (new, on the parsed commit / bump path) — keeps the commit available for version bump calculation while optionally excluding it from the rendered changelog body. That is the gap Distinguished behaviour between version bump and changelog #1579 hits: “count this commit for semver bump, but do not print it.”

So skip=true is stronger (invisible to bump + changelog). include_in_changelog=false is the narrower “bump-only / hide from body” knob.

CI “Test suite” / “Links” failures on the last run look infrastructure-side (Codecov GPG verify; lychee 403s on gitlab.com sign-in redirects) rather than assertion failures in the new tests — happy to re-trigger or adjust if you want anything else covered locally.

[arimu1]

@orhun Re-triggered CI. The two red checks look environmental rather than from this change:

• Test suite: codecov action fails on GPG signature verify for the uploader binary (Can't check signature: No public key), not cargo tests.
• Links: lychee reports 403 on gitlab.com/.../commit/... URLs (redirect to sign-in). Pre-existing website examples, not docs introduced here.

Happy to wait on infra recovery or adjust if you prefer another approach.