Closed carlescufi closed 1 year ago
I'm not necessarily against this, but it seems like a niche use-case.
Also, this behavior can already be implemented today: Add a boolean disabled
option to you user-defined rule that defaults to False
. You can then check at the start of your validate
method whether the rule is disabled and return early.
Technically, gitlint still runs these rules, but they will then be no-op.
If you really want to not have gitlint run these rules in the first place, you can also write a user-defined ConfigurationRule that filters out all config.rules
that have an attribute disabled=False
Also, this behavior can already be implemented today: Add a boolean
disabled
option to you user-defined rule that defaults toFalse
. You can then check at the start of yourvalidate
method whether the rule is disabled and return early. Technically, gitlint still runs these rules, but they will then be no-op.
This should be enough to cover my use case, thanks for the suggestion.
This is sort of an alternative to #395, but both could be implemented. The idea is that one could set some sort of
disabled = True
in the user-defined class implementation so that, although present in the extra-path, it would not run by default unless explicitly enabled in the command-line or.gitlint
.