custom_major/minor_increment_regex ignored for multiline commits when conventional_commits = false

[netanelzucaim]

Is there an existing issue for this?

• I have searched the existing issues

Description of the bug

Summary

When conventional_commits = false and a multiline commit is passed via --with-commit, git-cliff silently falls back to
a patch bump even when the commit subject matches custom_major_increment_regex or custom_minor_increment_regex. The
bump rules are completely ignored.

---

Configuration (cliff.toml)

[git]
conventional_commits = false

commit_parsers = [
{ message = "^breaking", group = "🚀 🚀 Breaking Changes" },
{ message = "^feat", group = "✨ Features" },
{ message = "^fix", group = "🐛 Bug Fixes" },
{ message = "^other", group = "📦 other", skip = true }
]

[bump]
custom_major_increment_regex = "^breaking"

[changelog]
trim = false
body = """
...
"""

I have intentionally disabled conventional_commits because my commit messages do not follow the type(scope):
description structure. They are free-form strings that start with a known prefix (breaking, feat, fix). The
custom_*_increment_regex fields exist precisely to support this use case.

---

Reproduction

Single-line commit — works correctly, bumps MAJOR

git cliff --config cliff.toml \
--tag-pattern '^nati-[0-9]+.[0-9]+.[0-9]+$'
--bump --bumped-version \
--with-commit 'breaking: remove v1 endpoints' \
-- HEAD..HEAD

→ nati-2.0.0 ✓

Multiline commit (subject + body, no blank-line separator) — WRONG, bumps PATCH

git cliff --config cliff.toml \
--tag-pattern '^nati-[0-9]+.[0-9]+.[0-9]+$'
--bump --bumped-version \
--with-commit $'breaking: remove v1 endpoints\nThis removes the entire /v1 API surface.'
-- HEAD..HEAD

→ nati-1.0.1 ✗ (expected nati-2.0.0)

The only difference between the two calls is a \n followed by body text. The subject line is identical.

---

Expected behaviour

When conventional_commits = false, git-cliff should evaluate custom_major_increment_regex and
custom_minor_increment_regex against the commit subject only (the first line), ignoring everything after the first
newline. This is consistent with how conventional commit parsing works — the subject is always the first line.

A commit starting with breaking should bump major.
A commit starting with feat should bump minor.
This should hold whether the commit is single-line or multiline.

---

Actual behaviour

When a multiline string is passed, git-cliff appears to fail to isolate the subject and applies no bump rule — falling
back to patch regardless of the prefix.

---

Workaround

Passing only the first line to --with-commit for bump calculation, then passing the full multiline string for changelog
generation:

bump call: subject only

bump_commit_args = " ".join(
f"--with-commit {shlex.quote(c.splitlines()[0])}" for c in commits
)

changelog call: full multiline

with_commit_args = " ".join(
f"--with-commit {shlex.quote(c)}" for c in commits
)

This is a functional workaround but requires splitting one logical operation into two separate git-cliff invocations.

---

git-cliff version: 2.10.1
OS: Linux

Steps To Reproduce

1. Create a test git repo

mkdir /tmp/cliff-test && cd /tmp/cliff-test
git init
git commit --allow-empty -m "initial"
git tag nati-1.0.0

2. Create cliff.toml

[git]
conventional_commits = false

commit_parsers = [
{ message = "^breaking", group = "🚀 Breaking Changes" },
{ message = "^feat", group = "✨ Features" },
{ message = "^fix", group = "🐛 Bug Fixes" },
]

[bump]
custom_major_increment_regex = "^breaking"
custom_minor_increment_regex = "^feat"

3. Single-line commit — works correctly

git cliff --config cliff.toml
--tag-pattern '^nati-[0-9]+.[0-9]+.[0-9]+$' \
--bump --bumped-version \
--with-commit 'breaking: remove v1 endpoints'
-- HEAD..HEAD

Expected: nati-2.0.0
Actual: nati-2.0.0 ✓

4. Same subject + body with no blank-line separator — breaks

git cliff --config cliff.toml \
--tag-pattern '^nati-[0-9]+.[0-9]+.[0-9]+$' \
--bump --bumped-version \
--with-commit $'breaking: remove v1 endpoints\nThis removes the entire /v1 API surface.' \
-- HEAD..HEAD

Expected: nati-2.0.0 (subject still starts with breaking)
Actual: nati-1.0.1 ✗ — patch bump, bump rules silently ignored

5. Confirm the subject alone still works

git cliff --config cliff.toml \
--tag-pattern '^nati-[0-9]+.[0-9]+.[0-9]+$' \
--bump --bumped-version \
--with-commit 'breaking: remove v1 endpoints' \
-- HEAD..HEAD

Expected: nati-2.0.0
Actual: nati-2.0.0 ✓ — stripping the body to subject-only restores correct behaviour

---

The only variable between steps 3 and 4 is the \n followed by body text. The subject breaking: remove v1 endpoints is
identical in both.

Expected behavior

When conventional_commits = false, git-cliff should evaluate custom_major_increment_regex and
custom_minor_increment_regex against the commit subject only (the first line), ignoring everything after the first
newline. This is consistent with how conventional commit parsing works — the subject is always the first line.

A commit starting with breaking should bump major.
A commit starting with feat should bump minor.
This should hold whether the commit is single-line or multiline.

Screenshots / Logs

No response

Software information

git-cliff version: 2.12
OS: Linux

Additional context

No response

[niklasmarderx]

I ran into the same area while working on #1456 (include-path fixture tests). The root cause is likely that custom_major_increment_regex and custom_minor_increment_regex are matched against the full commit message string rather than just the subject (first line).

When conventional_commits = true, the subject is extracted during conventional commit parsing before bump evaluation. But with conventional_commits = false, the raw --with-commit string (including \n + body) goes straight to the regex match — and ^breaking anchored at the start doesn't match when the engine treats the input as a single string containing newlines.

A minimal fix would be to split on the first \n and only pass the subject line to the bump regex evaluation when conventional_commits = false. Happy to look into a PR for this if it helps.

[orhun]

Thanks for the detailed bug report (@netanelzucaim) and looking into the root cause of this (@niklasmarderx)!

I would be happy to review a PR for this, so go ahead! Just for context, these configuration values actually come from the next_version library, in case anything needs to be adjusted there as well.

• https://docs.rs/next_version/latest/next_version/struct.VersionUpdater.html#method.with_custom_major_increment_regex