Clarification on recent multi-line change

[snuggie12]

In #68 there's now a check for an extra blank line. Given the wording in the release notes and in the output message if you fail the check I more read this as you need a blank line if you have a body:

Conventional Commits start with one of the below types, followed by a colon, followed by the commit subject and an optional body seperated by a blank line:

I require a blank line even if I don't supply a body.

I think there are a few possibilities here:

• This was unintentional and we need to fix
• This was intentional and I feel the messaging could be a bit clearer

If the 2nd one, what do you think about drawing more attention to it in the program? Can it be made bold or surrounded by *** or something to draw attention to it for a few versions and then special messaging can be deprecated?

[snuggie12]

It appears to work if you use -m to provide your message. However, if using an editor it breaks.

[nikolaik]

Is this because when using an editor it usually adds a newline at the end of the file, tripping up the regex?

[snuggie12]

Is this because when using an editor it usually adds a newline at the end of the file, tripping up the regex?

@nikolaik sort of but the opposite. The editor adds comments. The regex sees this as multiline and therefore requires an additional blank line. So the fix would be to treat comments as comments and determine the message as a single line and therefore no blankline is required. Example of the breaking commit in the editor below:

fix: test message
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch foo
# Your branch is up to date with 'origin/foo'.
#
# Changes to be committed:
#       modified:   foo

[thekaveman]

Thank you @snuggie12 and @nikolaik for the report and conversation.

I'd say this is a bug in our implementation -- we should definitely support commit messages from an editor, in addition to the command line. My workflow is mostly the latter, so I probably missed this detail for editor-based messages.

A PR to fix this would be most welcome!

[nikolaik]

Gave a try at handling this in #87

[thekaveman]

Thanks again for the report @snuggie12 and your work on this @nikolaik

3.1.0 has been released in GitHub and PyPI with this fix.