[greentrust]

Is the cost really that high? For the vast majority of projects, all developers will need to do is run "yarn prettier".

We can't expect everything to be perfect on day one, nor should we be stuck with the poor choices we made when starting a project. Maintainers should be allowed to change their mind after careful consideration and community consensus.

[afshin]

Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.

[lonelappde]

Configure your git blame to ignore cleanup changes.

https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

[Waterluvian]

This changes everything. Thank you!!!

[davidmurdoch]

If GitHub doesn't automatically support the feature (article says it doesn't) I don't think it'll be very useful for many teams.

[capableweb]

If you can use GitHub but not Git, I'm not sure you can really say that you know version control. Fine for designers who are just helping out in projects and don't really know to but developers who manages merges, backports and alike should really know the insides of Git, not just the GitHub GUI.

[nchase]

git 2.23 isn’t that old - seems like something that GitHub could support in the future

[29athrowaway]

Thanks for sharing this. This issue is holding so many code bases behind.

[Groxx]

--ignore-rev: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

Personally tho I haven't had an issue navigating back another revision. UIs are good at handling that kind of interaction, and I rarely use blame without a UI. (nearly every other git interaction: CLI all the time. but not blame.)

[akiselev]

The loss is a bit of convenient tooling but it can be replaced with some slightly less convenient tooling. It's not going to be an architectural limitation and you can treat it as a relatively simple per company/team/project tradeoff.

Especially when working with syntax heavy compiled languages like Rust, autoformat on save frees me up enough mental capacity for me that the costs are well worth it for the extra development speed. I just use Git Lens and some custom git aliases to get around the messy logs, whereas my last team handled the payment frontend for a large company so tracing the history of changes was taken way more seriously and reformatting someone else's code outside of organized refactorings, let alone autoformat, was disqualified from the start.

[Waterluvian]

This used to have no value to me. But years into my career I discovered that I can't live without it. Detective work on the history of code is vital to truly groking why things are the way they are in code bases.

[random3]

It will likely conflict most in-progress PR. For PRs that are large and long lived it will be a PITA to maintain and will further slow integration so, likely, yes.

[globular-toast]

I ran formatters on a largish codebase over Christmas when all the PRs were done. You just have to pick your moment. If it's really hard then get everyone to agree on a date to do it and make it each developer's responsibility to either merge before or rebase after the change. It can be done.

[random3]

Some team in my old job use to have a term for this - "grabbing the virtual chicken". It was essentially a giant distributed lock :)