Commitlint: Empty commit message throws error

Created on 5 Apr 2019  Â·  7Comments  Â·  Source: conventional-changelog/commitlint

Providing an empty commit message (normally used to abort committing in git), throws an error message. Length is being used without checking that it is avaible

Version 7.5.2

TypeError: Cannot read property 'length' of null
    at exports.default (./node_modules/@commitlint/rules/lib/header-max-length.js:10:143)
    at results.filter.map.entry (./node_modules/@commitlint/lint/lib/index.js:138:17)
    at Array.map (<anonymous>)
    at Object.<anonymous> (./node_modules/@commitlint/lint/lib/index.js:118:7)
    at process._tickCallback (internal/process/next_tick.js:68:7)
husky > commit-msg hook failed (add --no-verify to bypass)
bug

Most helpful comment

I can also reproduce this by running git commit and then aborting & exiting vim with just :q! (without writing anything).

All 7 comments

Thanks for reporting!

Hey @eddiemonge , what config are you using?
With a default config I do not get an error:

git commit -m ''
husky > commit-msg (node v10.1.0)
✔   found 0 problems, 0 warnings
    (Need help? -> https://github.com/conventional-changelog/commitlint#what-is-commitlint )


Aborting commit due to empty commit message.

Creating an empty message using --amend also works.
Could you provide more info? Thanks

@escapedcat I can reproduce this by running git commit and exiting vim (:wq) right away, without writing anything.

^^ this. I should have been more specific. I didn't test with an empty message -m ''.

@escapedcat what do you think is the proper solution?

  1. Add a fallback to the rule(s) to let them pass or "not-error" on null commits.
  2. Convert null input to an empty string before testing
  3. Not run anything testing/rules at all and just ignore it?

I'll make a test for this now, without any fix implementations yet.

Normal git behaviour would be:

git commit
Aborting commit due to empty commit message.

Which is kinda what we get currently with -m ''.
I would think it should behave like this, yes?

I can also reproduce this by running git commit and then aborting & exiting vim with just :q! (without writing anything).

Was this page helpful?
0 / 5 - 0 ratings