Add support for multiple ignore-* rules in configuration file

[jmaupetit]

Hi there 👋 Thank you for providing this amazing project to the community!

I recently stumbled upon a disturbing issue: we cannot define multiple ignore-by-title sections in the .gitlint configuration. It means that I cannot define different rules to ignore given a particular regex.

Did I missed something?
Is this a limitation of the ini/cfg format?

[jorisroovers]

Hi, thanks for your interest!

It's actually both a limitation of the ini format as well as the way gitlint handles rules: it can only have a single instance of each rule configured. I believe that makes sense, because you can't have e.g. 2 different title-max-length rules defined without causing ambiguity.

I actually did think about your case when writing the ignore-by-* rules in the last gitlint release, but wanted to keep things simple at the time since it was the first iteration. Also, I believe the simple (but somewhat bad-looking) workaround is to just write a more complex regex that includes all your simpler regexes:

regex=((<regex1>) | (<regex2>) | ... | (regexN))

I considered making the regex option a list instead of a single string so you could do:

regex=<regex1>,<regex2>,...,<regexN>

But decided against it because you can't unambiguously parse that list (the commas might be part of the regex instead of the list-separators). Also, syntax-wise, this is almost the same as doing ((<regex1>) | (<regex2>) | ... | (regexN)).

Long story short, I don't think supporting multiple of these rules is a quick fix, so if possible I'd recommend going with my suggestions above. I might look into this in the future, but as often, it might take me a few or more months (this is a hobby project and I tend to work on it for a few days about 2-3 times a year).

[jmaupetit]

Thank you for your quick answer @jorisroovers! I came to the same conclusion and used a more complex regex. But doing so exclude the possibility to ignore a specific rule for a particular regexp: we are constrained to ignore an aggregation of all rules we want to ignore.

As I am using YAML a lot these days, I think switching the configuration to this file format would add more flexibility. But it's a huge refactoring...

[jorisroovers]

Unfortunately YAML alone wouldn't fix this, it also has to do with how gitlint stores rules internally (only 1 instance of each rule can be active at once).

I don't think we necessarily need to support multiple of the same rules though.
I believe what we need is to allow users to add a mapping in the ignore rule that allows them to specify multiple regexes to be mapped to different lists of rules to ignore.

For example:

[ignore-by-title]
regex1=<regex1>
ignore1=title-max-length,body-min-length
regex2=<regex2>
ignore2=all

While I agree that we YAML would allow us to do this using nicer syntax, I think these number-based (regexN, ignoreN) tuples are an acceptable trade-off.

For backwards compatibility we'd just internally map regex, ignore to regex1,ignore1.

Interested to hear your thoughts :-)

(Again, probably won't actually work on this for a while, but definitely something I'll consider doing at some point.)

[jmaupetit]

it also has to do with how gitlint stores rules internally (only 1 instance of each rule can be active at once).

True, that why I've said that it would be deep refactoring.

I like your proposal, let's do this!

Nothing hurries, let's keep in touch and keep up the good work! 💪

[jorisroovers]

2+ years later...

I just implemented 'Named Rules' which allows users to have multiple of the same rule active at the same time, like so:

# .gitlint file

[ignore-by-title:first-instance]
regex=(.*)ignore(.*)
ignore=all

[ignore-by-title:second-instance]
regex=(.*)foobar(.*)
ignore=B6

[ignore-by-title:thisCanReallyBeWhateverYouWant]
regex=(.*)hurdur(.*)
ignore=T2,T3

Of course it's possible to create conflicting rules this way, but that's up to the user to make sure that doesn't happen.

This should solve this use-case :) This will go out as part of 0.14, somewhere in next few weeks.