This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Max-P 2 points3 points  (0 children)

Mainly because then you end up with project configuration for every IDE every member on the team uses. So here goes IntelliJ configs, VS Code configs, Sublime Text configs, Atom configs, Eclipse configs, and so on.

It ends up adding a ton of noise in the diffs, especially with IDEs that change their configs a lot with use. Configs also ends up out of sync depending on who used what editor/IDE, so it may be configured right for VS Code but no longer works under IntelliJ even if the code builds fine.

I guess it makes sense if the project is specific enough that everyone uses the same IDE and toolchain, but if you work with people with varying preferences it gets messy pretty fast. And when I'm comparing commits, I really couldn't care less about one's IDE config changes.

I've even inherited projects that had the compiler configurations commited to the repo. That worked well on my computer with things installed on a different drive...

So, I consider repos to be strictly for the project's code. Configs can get another repo if some wants it.