Black: format SCM diffs only

[gaborbernat]

Feature request: for projects not fully adopting black yet, would be nice if we could have some way of using black on the diffs only. I understand this is a non-trivial task. But should be possible to somehow get the diff against HEAD and keep only lines from that. Taking over the world one commit at a time?

[ambv]

That goes against PEP 8 (consistency within a file) and the philosophy of Black. For adoption it's a better experience to create one sweeping commit that is easy to omit in git blame, rather than mix formatting changes with semantic changes for a long time.

We need a section of the docs that explains this.

[gaborbernat]

I see. I was thinking more along lines for projects that have no true one style, that already violates pep 8.

[Lukas0907]

You can always reformat the whole file, and discard irrelevant changes with git checkout -p $FILE.

[crdoconnor]

For adoption it's a better experience to create one sweeping commit

I think that's a bad idea:

• Rewriting code is inherently dangerous. Black's reformatting could cause a subtle bug (if it does, it is unlikely to be picked up on an enormous pull request) which might not be detected until it causes major problems. If its changes were isolated to pull requests that will actually be read then the chances of that happening are minimized.

• It will still damage the usefulness of git history. You will be able to "git blame -i {sweeping commit}" provided you are using git blame on the command line, but if you use, say, annotate in pycharm or blame in github that option isn't available and those tools are rendered useless.

[carljm]

Rewriting code is inherently dangerous. Black's reformatting could cause a subtle bug

Black's reformatting is AST-safe; the AST resulting from parsing the reformatted code is identical to the AST prior to the reformat. Black checks and verifies this identity. Therefore, the only way a Black reformat could cause a bug is if you have code doing something really unusual and unadvisable, like reading Python files from disk and manually parsing them with a regex, or similar.

[ambv]

It will still damage the usefulness of git history.

blame != history. It's cleaner to have a single point in history reformatting everything, rather than a sprawling number of diffs that make semantic changes and move tokens around to improve style.

The easiest way to ignore a sweeping commit with git is git hyper-blame. If you don't want to or can't use that, then using git blame $BLACK_COMMIT^ -- $FILE is what you want (note the caret). You can easily replicate that in the GUI by clicking on a link to $BLACK_COMMIT (will be next to any line that is still blamed to this commit), going one commit up, and looking at blame of the file you're interested in then.

Compare that with looking at the blame of a file that's riddled with commits that change formatting around a semantic change, too. They will necessarily touch unrelated lines immediately around the semantic change, poisoning the visible history without a single revision that you can step over.

Rewriting code is inherently dangerous.

As Carl says, it's not. I reformatted tens of millions of lines of code with it by now. I could only confidently do this because of the sanity checks that Black performs.

[gaborbernat]

Will not fix it is then :+1:

[wbolster]

fyi, i wrote https://github.com/wbolster/black-macchiato