Black, the uncompromising Python code formatter, is stable

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.

[ Parent | on HN ]

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...

[ Parent | on HN ]

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

[ Parent | on HN ]

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

[ Parent | on HN ]