How do I prevent a non-existent field (from an unconventional commit) from trashing the commit?

[GideonBear]

[git]
conventional_commits = true
filter_unconventional = false
require_conventional = false
commit_parsers = [
    { field = "breaking", pattern = "true", group = "breaking changes" },
    { message = "^.*", group = "other" },
]

All unconventional commits are trashed because Field error: `field 'breaking' is missing or has unsupported type (expected a String, Number, Bool, or Null — or an Array of these scalar values)`.

• feat: some feature -> other
• feat!: some breaking feature -> Breaking changes
• some unconventional commit -> error, trashed

I understand why this happens, but I cannot figure out how to prevent this.
I tried field = "breaking | default(value=false)" but that just errors on every commit, presumably because field accepts only dot notation and not arbitrary tera expressions.

[ognis1205]

• feat!: some breaking feature -> Breaking changes

As far as I know, git_cliff_core::Commit does not define a breaking field. With that in mind, I would expect this configuration to cause a FieldError for every commit, resulting in nothing being rendered in the changelog.
Under the configuration you shared, it seems that all commits should trigger a FieldError, so I'm a bit confused about how the grouping you described would occur. Could you clarify?

All (unconventional) commits are trashed because Field error: `field 'breaking' is missing or has unsupported type (expected a String, Number, Bool, or Null — or an Array of these scalar values)`.

If your repository follows Conventional Commits and includes a BREAKING CHANGE: footer for breaking changes, I would suggest grouping based on the footer instead:

https://git-cliff.org/blog/2.4.0#-parse-commits-by-footer

In that case, you could use the footer matcher rather than relying on a non-existent breaking field. This approach should avoid triggering a FieldError, since it would only attempt to match against existing footer entries rather than resolving a missing field.

If you are not using footers for breaking changes, you can match them directly in the commit message like this:

commit_parsers = [
    { message = "^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\\([^)]+\\))?!", group = "breaking changes" },
    { message = "^.*", group = "other" },
]

[GideonBear]

As far as I know, git_cliff_core::Commit does not define a breaking field. With that in mind, I would expect this configuration to cause a FieldError for every commit, resulting in nothing being rendered in the changelog.
Under the configuration you shared, it seems that all commits should trigger a FieldError, so I'm a bit confused about how the grouping you described would occur. Could you clarify?

My config works.

$ cat cliff.toml
[git]
conventional_commits = true
filter_unconventional = false
require_conventional = false
commit_parsers = [
    { field = "breaking", pattern = "true", group = "breaking changes" },
    { message = "^.*", group = "other" },
]
$ git log --oneline
5cb0213 (HEAD -> main) feat!: breaking
2203bcb chore: Add git cliff config
0decf7b this is an unconventional commit
a306d55 feat: this is a conventional commit
$ git-cliff
 WARN  git_cliff_core::changelog > 1 commit(s) were skipped due to field error(s) (run with `-vv` for details)
## [unreleased]

### Breaking changes

- [**breaking**] Breaking

### Other

- This is a conventional commit
- Add git cliff config

The context page in the docs says it exists, but crucially only for conventionally-parsed commits. I got the inspiration from here and I swear some other issue where field = "breaking" was referenced in a config directly but I can't find it.

Thanks for the tip about the footer and the explicit matching, it's not ideal, but I guess I can add a parser for the footer and one for the !!

[ognis1205]

My bad, I completely forgot about the custom Commit serialization implementation. Your configuration is indeed valid. Thanks for pointing that out.

I also understand that this behavior can be inconvenient. Taking into account the issue you shared, we may revisit this from a specification perspective in the future. If you have any thoughts or proposals, please feel free to leave them in the discussion or open an issue, that would be greatly appreciated.

[GideonBear]

It looks like #1015 also contains some of the same problems I have:

I've tried to implement this but filtering is currently impossible because if a commit does not follow the conventional-commits format its breaking field is missing from the context (or maybe its null?), instead of being false.