Thinking on the feature of "run repolinter on a specific branch instead of default", I'd approach it by enhance the -g git cli option by allow "repo:branch" on top of just "repo", need to look into how to achieve that with simple-git.
That's allow enable the repo linter to:

1. Run any branch/commit/tag following the general repo:branch, repo:commit convention.
2. Run on all ruleset instead of limited subset of rulesets.
3. Make the cost (time for running repolinter) clear to the user, customer would need to curate a list of branch and run in a script, can do easy math to get the total run time.

Thinking on the feature of "run repolinter on a specific branch instead of default", I'd approach it by enhance the -g git cli option by allow "repo:branch" on top of just "repo", need to look into how to achieve that with simple-git.
That's allow enable the repo linter to:

Thanks for commenting!

I see where you are coming from, the problem with that approach is that you can't configure this per rule. You will lose the ability to run rule X for just the default branch, while running rule Y for various branches (all within the same ruleset).
For many rules, it does not make sense to check multiple branches.

I see. In that case, may I request to move the feature change away from file-contents and setup its own rule?
Reason being:

1. All current rules are working with traditional file/dir, this would be the first rule that directly working git, I think it's necesasry to call that out and make it a separate rule, maybe git-file-contents. The new rule can invoke file-contents.
2. The test cases for this feature would be cleaner, limited to testing sequential git/file-contents.

My couple of thoughts here are:

• I don't understand what 'sequentialOnly' is for. As a parameter it sounds like it is telling something not to run in multiple threads; but CLI-UI wise, it's not clear what that something is. It doesn't seem introduced by feat: add any-file-contents rule #290.
• +1 for exploring as a separate rule.