[idea] gradual shading of repo to black

[webknjaz]

What I mean is that high-volume, actively developed repos it might be unable to afford reformatting of the entire code base at once.
Instead, it would be less painful and non-blocking if bot could do blackening file by file or even better - update chunks and send new PRs once previous have been merged. It could even do bigger chucks against rarely changed code at the beginning and slow down and be more picky about the code someone is currently editing.

[Mariatta]

Yup, so what we can do is, in the commanding issuee, provide a list of files/paths to be blackened.
Then tell black to format those files only.

[webknjaz]

Yeah, I is similar to what I do with pre-commit tool: I exclude lots of files in config and then include them.

I would probably like to see this as a config in repo.

[Mariatta]

Hm I'm not a fan of yet another configuration file.

[webknjaz]

Well, it's the easiest way of keeping configs of all repos, where GitHub App is installed. Otherwise, you'd have to implement some per repo state management on the server side or some UI.
As a user I'd like to be able to explore what the current config is easily, seeking for the answer for: "Which files are currently blacken or of certain shade of black?"

[Mariatta]

So I'm thinking of providing a config file where we can specify which paths are to be blacked out.
My use case now is core-workflow repo, where I'd like cherry-picker to be blacked out, but not blurb.

So maybe a .black_out file at the root of the repo.

[webknjaz]

I'd say .black_out.yaml (toml?) in root or under some subfolder like .github/ (with some precedence).
But it also could be pyproject.toml section (which feels more relevant to Python projects).

[webknjaz]

Remark: blackening files wholesale creates unwanted side effects. I saw ppl resisting to it because it messes up authorship in git blame, for example.
So I'd also suggest that this tool might try to preserve this by splitting commits and setting correct authors.
It also could try adding new commit on top of PRs only changing the diff part.

[webknjaz]

Further ideas: use a brand-new change suggestions feature to send chunk changes on top of PRs. https://blog.github.com/2018-10-16-future-of-software/#suggested-changes-public-beta

[Mariatta]

I think "suggesting change" is available through GitHub web UI, not through APIs.

[webknjaz]

@Mariatta so this feature is nothing more than "```suggestion" type of the markdown code block. I bet it should work for the bot posting a comment to the position in diff.