Heinrich Langos

> @atosatto We fixed this a while back but it was reverted or we mixed it up. It's inventory_hostname vs fqdn. @till I thought the same and tried to work...

It *sounds* fantastic!... But I don't know enough about golang to know if "interpreting" go code in string interpolation is easily implemented. I was under the impression that golang is...

It would indeed be great, to have the power to evaluate golang inside those value strings. I wonder if/how one could make the current headers of the request (or response)...

Yeap. That sounds like we need a whitelist. I'd suggest a configurable list of regex with a default set that contains all those regex from [conventional-changelog](https://github.com/conventional-changelog/commitlint/blob/master/%40commitlint/is-ignored/src/defaults.ts)'s implementation.

This looks like the parser picks the **last** `:` instead of the **first** one, to separate `type(scope)` from the rest of the header.

Found it! The bug is not in `commitlint` itself, but in [conventionalcommit/parser](https://github.com/conventionalcommit/parser) And it is slightly different than I thought. The parser doesn't work with regex but uses a lexer...

Seems like this will have the same solution as #10 .. a whitelist of regex that, when matching the commit's first line, mark this commit message as OK.

I like that idea... I just had the same annoying experience. I wrote a lengthy commit message, `commitlint` said NO, and my long commit message was gone. Unfortunately I think...

Another idea might be a little more intrusive, but more helpful ... :thinking: If we decide to fiddle about with git-config, we might save the "bad" message in a file...

Yes, it would be lovely to have the `git commit`'s [cleanup of comments and verbose diff](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---cleanupltmodegt) happen before commitlint sees the message. This would shift the burden of maintaining the...