You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there an existing issue or pull request for this?
I have searched the existing issues and pull requests
Feature description
Right now unconventional commits are not parsed at all: regardless of the conventional_commits value, as soon as the commit is identified as unconventional, the parsing into message, body, and footers does not happen.
However, still parsing the message might be useful in certain circumstances:
commiter made a mistake when adding commit type (forgot, typo, etc), so this commit will never be recognized as conventional, and we can't extract its parts
conventional_commit is set to false in the config file, but we still want to filter/process e.g. footers
for unconventional commits, changelog will contain the entire commit message (possibly lots of lines), even if we only need the first line (commit.message) and not the rest (commit.body)
I believe that having an option to enable commit message parsing for all commits, regardless of their type, solves many such problems,
I also believe that having a relatively established format convention (footers are recognized by git, and message is separated from the body by a single blank line, which is respected by git log --oneline) makes this feature not very controversial, even when conventional commit spec is not followed by the dev team, but they want to use git-cliff for changelog generation.
Last but not least, thanks a lot for a great product, your work is very much appreciated!
Desired solution
New configuration option "parse_commit_message" with possible values "always", "never", "conventional_only" (default value, compatible with current behaviour).
Whitespace characters should be trimmed from each parsed part of the commit.
Alternatives considered
Using built-in templating filters is possible in certain cases.
Additional context
No response
The text was updated successfully, but these errors were encountered:
This is already possible, you need to set filter_unconventional to false and create appropriate commit parsers depending on your commit format for overriding different parts of the conventional commit such as group and scope. For example:
[git]
# parse the commits based on https://www.conventionalcommits.orgconventional_commits = false# filter out the commits that are not conventionalfilter_unconventional = false# regex for parsing and grouping commitscommit_parsers = [
{ message = '^fix\((.*)\)', group = 'Fix (${1})' }
]
Is there an existing issue or pull request for this?
Feature description
Right now unconventional commits are not parsed at all: regardless of the
conventional_commits
value, as soon as the commit is identified as unconventional, the parsing into message, body, and footers does not happen.However, still parsing the message might be useful in certain circumstances:
conventional_commit
is set tofalse
in the config file, but we still want to filter/process e.g. footerscommit.message
) and not the rest (commit.body
)I believe that having an option to enable commit message parsing for all commits, regardless of their type, solves many such problems,
I also believe that having a relatively established format convention (footers are recognized by git, and message is separated from the body by a single blank line, which is respected by
git log --oneline
) makes this feature not very controversial, even when conventional commit spec is not followed by the dev team, but they want to usegit-cliff
for changelog generation.Last but not least, thanks a lot for a great product, your work is very much appreciated!
Desired solution
New configuration option "
parse_commit_message
" with possible values "always
", "never
", "conventional_only
" (default value, compatible with current behaviour).Whitespace characters should be trimmed from each parsed part of the commit.
Alternatives considered
Using built-in templating filters is possible in certain cases.
Additional context
No response
The text was updated successfully, but these errors were encountered: