If almost everyone uses some editor, then it’s not really “littered”. We do the same and it’s nice for new teammates to quickly get set up. If they are one of the few folks that want to use some other editor, who cares? Files are free.
When almost everyone uses the same editor, it doesn't mean that everyone wants to have the same configuration.
Editors and IDEs are crafting tools. Crafting tools are meant to be mastered by workers (here: developers), not to enforce some team/company policy.
There are tools that already exists to enforce team policies like formatters, linters and so on. These tools generally integrate well with your editor of choice and can also be integrated on your CI pipelines.
I feel like a better option than committing is to have developers submit sample configurations and make them available in a subfolder or a dedicated configuration repo -- this way, newcomers to the team can pull in existing configurations and tweak them, rather than having to start from zero.
I said it makes sense iff everyone uses the same editor and the same settings. But many times this is not the case.
What do you need to share btw? There's editorconfig, prettier, git hooks, etc. for style. direnv for configuration (I usually commit a .envrc.example file). I can't think of anything else.
At my last job we had a mono-repo with the .idea directory (for IntelliJ) commited. For Java projects IntelliJ needs to sometimes be directed to understand what folders are “resources” to allow better autocompletion and highlighting.
For example specifying custom java faces components directory that will be used once the application is packaged into a war file, so IntelliJ knows they are accessible from JSP html files, and will autocomplete and show you what attributes you can modify on the component.
I had a dev check in their .idea directory and all the files for a project. This resulted in them checking in the file that had windows and cursor positions checked in too. Each time you went to switch to a different branch, you got the workspace configuration of the last person to commit that file.
Another spot of problems was the plugin specific files (that inevitably also got checked in). When someone checked them in again and you hadn't updated this particular plugin, the newer file format caused it to crash. Not a problem for the dev who checked it in, but a problem for everyone else.
I am a strong proponent now of not checking in files that are IDE specific unless the developers are all completely aware of what files do what and the associated churn that a file may have through normal use.
Having maven and editorconfig instruct IntelliJ on how to make a workspace consistent results in less config file churn and avoids people accidentally checking in the compiler settings on their computer, database configurations (with passwords), run configurations (with passwords) and similar.
Checking in IDE files can be done, just that the developers all need to be diligent in checking what they check in. I've rarely been in an environment where that is the case for everyone.
They didn’t say “your” model, they said “the” model.
Presumably they meant “the prevailing model”, that you partly (accurately, in my view) describe. And by wrong, I guess they just mean “bad” and not what they want, because the rest of the comment describes some hopes and dreams.
That too will cause social unrest, indeed. But we won’t suffer social unrest today just to make tomorrow easier, however wise that might be. We’ll kick the can.
Being right isn’t the only most important thing in the world, nor does it wash away all transgressions.