Dealing with repositories that have parse-failing commits?

[f0ff886f]

I'm trying to adopt git cliff, and so far its quite nice, but its also quite strict which makes it hard to adopt mid-project.

I have a range of commits that are simply not conventional, and every time I run git cliff I get the WARN log line that 11 commits were skipped.

The RANGE command line argument works perfectly, but what is the best way to encode that inside the cliff.toml so I don't have to remember it every time?

Also, what are we supposed to do with MR commits from GitLab? They are often titled Merge branch 'feat/ci' into 'main', or have specifically something like:

commit 50de45d3b2025824e812245f940294df873c748b (tag: v1.0.0)
Merge: e0012cc 879184e
Author: Matt <matt@email.com>
Date:   Mon Feb 16 11:12:03 2026 -0800

    Merge branch 'feat/ci' into 'main'

    chore(ci): Add GitLab CI to build release binaries

    See merge request matt/test-tool!1

This now also creates a warning each time...

[ognis1205]

Hi @f0ff886f , thanks for raising this 👋

Would you mind sharing your current cliff.toml configuration?

[f0ff886f]

It is spartan... I started with 1.0.0 as I didn't want to go through any 0.x.y releases in this test.

# git-cliff ~ configuration file
# https://git-cliff.org/docs/configuration

[bump]
initial_tag = "1.0.0"

[ognis1205]

Thanks for sharing your config!

I have a range of commits that are simply not conventional, and every time I run git cliff I get the WARN log line that 11 commits were skipped.

git-cliff provides a few configuration options to control how Conventional Commits are handled:

• https://git-cliff.org/docs/configuration/git#conventional_commits
• https://git-cliff.org/docs/configuration/git#filter_unconventional
• https://git-cliff.org/docs/configuration/git#require_conventional

If I'm understanding your issue correctly, I believe this can be addressed by adjusting one or more of these settings depending on how strictly you want to enforce Conventional Commits.

The RANGE command line argument works perfectly, but what is the best way to encode that inside the cliff.toml so I don’t have to remember it every time?

As far as I know, there isn't currently a way to configure RANGE directly inside cliff.toml. If remembering the CLI argument is inconvenient, one practical workaround would be wrapping git-cliff in a small shell script or something similar. If this feels like a feature that would be broadly useful, it might be worth opening an issue to gather community feedback.

Also, what are we supposed to do with MR commits from GitLab?

This can also often be handled using the same three settings mentioned above, depending on whether you want to include, ignore, or strictly validate those commits. If you'd like to transform or normalize commit messages (e.g. rewrite GitLab merge commits), the following option might be helpful:

• https://git-cliff.org/docs/configuration/git#commit_preprocessors

That allows you to preprocess commit messages before parsing, which can help clean up merge commit formats.

Happy to help!

[orhun]

Using preprocessors to clean up those commits might help. e.g. here is what we do in @ratatui: https://github.com/ratatui/ratatui/blob/main/cliff.toml#L113-L128