Open mschilli87 opened 2 years ago
Thanks for this! Before having a closer look, do you think these are related?:
@escapedcat:
[...] [D]o you think these are related?:
I don't see how that one would be related beyond the fact that they both deal with signed commits. It is asking for a new feature allowing to enforce signed commits. I am just asking to fix a bug where an unrelated already existing check is broken when applied to signed commits.
That one is entirely unrelated: It is about signing off commits using -s
/--signoff
which simply adds a specific line to the commit message footer and is commoly used as some sort of 'signature' in the sense that the commiter confirms code ownership or such things. My issue is with commits signed cryptographically via -S
/--gpg-signed
to prevent untrusted parties from modifying the source code once the commit is published.
Alright, thanks for you feedback.
Would you be motivated and have time to look into this and maybe create a PR for this?
@escapedcat
Would you be motivated and have time to look into this and maybe create a PR for this?
I am sorry but I have no experience with TypeScript or even simple JavaScript so I doubt I'll be able to come up with a viable solution by myself in a reasonable timeframe.
I am sorry but I have no experience with TypeScript or even simple JavaScript so I doubt I'll be able to come up with a viable solution by myself in a reasonable timeframe.
Alright, no worries
This is a follow-up to https://github.com/conventional-changelog/commitlint/issues/876.
The upshot is that I am getting
warnings for GPG-signed commits that actually do have leading blanks.
Furthermore, the very same commit messages do not trigger that warning when passed in from
STDIN
or when not GPG-signing the commits.My guess is that the original issue might have been 'resolved' when switching to the other computer by different Git default configurations on the two systems involved (the first one GPG-signing by default, the second one not).
Expected Behavior
When a message contains a blank line between header and body it should not trigger a
body-leading-blank
warning, regardless whether the corresponding commit was GPG signed or not.Current Behavior
When a message contains a blank line between header and body it does not trigger a
body-leading-blank
warning when passed in viaSTDIN
or queried from the Git log via a non-GPG-signed commit, but does so when queried from the Git log via a GPG-signed commit.Affected packages
Steps to Reproduce (for bugs)
Create test repository:
Write test commit message to a text file.
Create default commitlint config:
Ensure that commit message does not trigger a
body-leading-blank
warning when passed in viaSTDIN
:Create non-GPG-signed commit using that exact same message:
Ensure that commit message does not trigger a
body-leading-blank
warning when passed in via the non-GPG-signed commit:Create a temporary GnuPG home directory:
Generate a temporary GPG key:
Amend the commit to GPG-sign it without changing the commit message:
Observe the false-positive
body-leading-blank
warning when queried from the Git log via the GPG-signed commit:commitlint.config.js
```js module.exports = {extends: ["@commitlint/config-conventional"]} ```Context
See this blogpost by Mike Gerwitz for a nice writeup of why GPG-signing commits is a good idea. If I have to decide between using commitlint or GPG-signing my commits, I'll choose the latter.
Your Environment
This is on Gentoo using Node.js and Git from Portage but commitlint installed via
Furthermore, the Conventional Commits configuration module was installed via
For it to be found, I also had to add the following to my shell environment:
commitlint --version
@commitlint/cli@16.1.0
git --version
git version 2.34.1
node --version
v14.17.6
``