6 ms·

I remember we migrated 2+ million LoC to being formatted by Black at Dropbox. Our Livegrep instance with a custom Git blame implementation always crashed at th

by ublaze 5y ago

I remember we migrated 2+ million LoC to being formatted by Black at Dropbox. 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/024c9cab55da7bd3236fd88759c9735d6149b464 https://github.com/psf/black/commit/024c9cab55da7bd3236fd887... Glad to see it's now stable.

ublaze 5y ago
To clarify, the slow git push was likely custom pre-receive hooks being slow.
Operyl 5y ago
`another_really_really_long_element_with_a_unnecessarily_long_name_to_describe_what_it_does_enterprise_style` hahahahaha, I love that test case.
skrause 5y ago
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.
- glacials 5y ago
  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.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
  - terr-dav 5y ago
    Light automation: https://github.com/ipython/ipython/pull/12091/files https://github.com/ipython/ipython/pull/12091/files
- tr33house 5y ago
  looks like a `break` is missing after `has_special_comment` becomes True

by ublaze 5y ago

ublaze 5y ago

To clarify, the slow git push was likely custom pre-receive hooks being slow.

Operyl 5y ago

`another_really_really_long_element_with_a_unnecessarily_long_name_to_describe_what_it_does_enterprise_style` hahahahaha, I love that test case.

skrause 5y ago

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.

glacials 5y ago
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.txt---ignore-revs-fileltfilegt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
- terr-dav 5y ago
  Light automation: https://github.com/ipython/ipython/pull/12091/files https://github.com/ipython/ipython/pull/12091/files
tr33house 5y ago
looks like a `break` is missing after `has_special_comment` becomes True