Allow commit_parsers to fix unconventional commits

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

There are some similar existing issues I found, but none seemed quite the same.

I didn't decide to use conventional commits—somewhat testing my commitment to using them for CHANGELOG generation—until after several commits were pushed to my remote. Now I want to fix them, and prevent new ones from being pushed.

So I tried a configuration file containing this:

[git]
conventional_commits = true
require_conventional = true
commit_parsers = [
  # Rewrite history
  { sha = "20246539df88431c72d65d7d0d1b82fba3deec34", group = "<!-- 0 -->Added" }, # Initial commit
  # ...
]

But this still fails.

Docs do state,

Checking takes place after commit_parsers. Thus commits can be skipped by matching parsers.

So it seems this could work if not for what else those same docs say directly above that,

If set to true, this option takes precedence over filter_unconventional.

It seems the code is already checking for conventional commits in the right order, but unconventional commits have to be allowed into the processor pipeline first.

Desired solution

If filter_unconventional = false and require_conventional = true, allow unconventional commits to go through commit_parsers. If any come out the other end and still aren't grouped, then fail.

Alternatives considered

I tried fail_on_unmatched_commit = true but couldn't seem to find a way with 2.14.1 to "fall back" to no matches based on match criteria available to me. Maybe there's a way, but docs seem to support that this feature request should've already worked.

Additional context

I used git cliff -vv to find the unconventional commits initially, but turns out short SHAs that were printed to the terminal weren't supported in git.commit_parsers.sha. I opened #1638 to track.