Add new ruleset, gitignore, with rules required_patterns and forbidden_patterns

[paulo-ferraz-oliveira]

It'll use files identified by dirs+filter (which should be .gitignore) and apply
(at the moment, the only existing) rule gitignore_patterns with the default value found in the documentation.

Closes #316.

Considerations

• rule name gitignore_patterns is up for discussion replace with two rules: required_patterns and forbidden_patterns
• config. option all_of (name and content) is up for discussion the option name shall be regexes
• ruleset name gitignore is up for discussion (though I'm rather fond of it)
• implementation in elvis_project is up for discussion (the implementation itself, too, but I'm talking more about the placement of the code)
• we may have to revisit the "since" once we discuss when to release stuff tentatively make it 4.0.0
• the need for further tests is up for discussion
• the error message is up for discussion

[elbrujohalcon]

Can we make two rules, as follows?

• required_patterns: for stuff that must be present in the file (i.e., the current rule)
• forbidden_patterns: for stuff that must not be present in the file (including, for instance, rebar.lock)?

And maybe we can put them in their own module (elvis_gitignore or something like that), instead of elvis_project?

[paulo-ferraz-oliveira]

Can we make two rules, as follows?

Why not options?

[paulo-ferraz-oliveira]

And maybe we can put them in their own module (elvis_gitignore or something like that)

rebar_config and elvis_config are part of "project", which is what this rule wants to be. Why should we separate into different files?

[elbrujohalcon]

Can we make two rules, as follows?

Why not options?

Mostly to have a ruleset with 2 rules, instead of one. 😜

[elbrujohalcon]

And maybe we can put them in their own module (elvis_gitignore or something like that)

rebar_config and elvis_config are part of "project", which is what this rule wants to be. Why should we separate into different files?

Fair enough. Let it be in elvis_project. :)

[paulo-ferraz-oliveira]

Brujo I think you need to update the settings for this

[paulo-ferraz-oliveira]

If it's not much, would you check the stuff above (initial description) that needs to be updated (?) - or maybe the checks are blocked to the author?

What's missing?

[elbrujohalcon]

If we're going to go with a single rule instead of 2… For the options I prefer the names include and exclude. Even more, include_patterns and exclude_patterns.

[elbrujohalcon]

FWIW… I would still prefer to have 2 rules, one for what needs to be included and one for what needs to be excluded… so that we don't need to deal with the priorities of the application of the filters. In other words, if the user wants to put a rule to include "rebar*" and a rule to exclude "rebar.lock"… it's up to them to put a line for a rebar thing that's not rebar.lock.

[paulo-ferraz-oliveira]

Yeah, excludes makes sense: I was initially just thinking about my use case. Would the default list be empty?

[elbrujohalcon]

No, it should have rebar.lock. 😉
And maybe elvis.config 🤪

[paulo-ferraz-oliveira]

I'm assuming rebar.lock is really something you want, and the other one was a joke 😄.

[elbrujohalcon]

You're 100% right.

[elbrujohalcon]

I think I still prefer to have 2 rules: one for required patters and one for excluded patterns. In that case, I would call the option just patterns or (to match other rules) regexes.

[paulo-ferraz-oliveira]

We can go with two rules, sure. One's the mirror of the other one so duplicating code and tests + adjusting shouldn't take long.

[paulo-ferraz-oliveira]

I've updated the description: I'm gonna make it two rules, each with the same option name. And I'm tentatively saying "since" is 4.0.0.