Re:Black, the uncompromising Python code formatter, is stable
by skrause on Saturday January 29, 2022 @05:02PM
(#30130991)
When I switched the company to Black, I reformatted the whole repository history with it. Every developer had to clone the repository again and reapply their local changes to it, but in the end it was a good choice because "blame" still works perfectly since we don't have one big reformatting commit.
Re:Black, the uncompromising Python code formatter, is stable
by glacials on Saturday January 29, 2022 @05:17PM
(#30131139)
An alternative is to use Git's blame.ignoreRevsFile[1] option to ignore specific commits when calculating blames. The downside is that although you can save the list of commits in the repo, you cannot do the same for the config setting itself, so it calls for some light automation at scale.
[1]: https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
Re:Black, the uncompromising Python code formatter, is stable
by terr-dav on Saturday January 29, 2022 @09:20PM
(#30133192)
Light automation: https://github.com/ipython/ipython/pull/12091/files
Re:Black, the uncompromising Python code formatter, is stable
by tr33house on Sunday January 30, 2022 @01:07AM
(#30134540)
looks like a `break` is missing after `has_special_comment` becomes True
Our Livegrep instance with a custom Git blame implementation always crashed at the commit made to do the migration :-) We had to pause our merge queue because we didn't want to run into conflicts, and I remember the `git push` ended up taking a while.
There was only one change that we had to make to Black to get it working on our codebase - https://github.com/psf/black/commit/024c9cab55da7bd3236fd887...
Glad to see it's now stable.