This mindset is how you get lots of IDE/dev-env-specific/platform-specific cruft inside of repos instead of pristine repos. It makes both contribution and maintenance difficult over time. While less of an extreme issue as IDE/dev-env-specific/platform-specific hacks/scripts littering the repo, gitignore entries should be generally justifiable, not ever-growing cruft to be added by each developer specific to their situation.

Fair, but it depends how uniform the culture is around a particular project. Is it haskell and everyone is using emacs? Sure, include those. But trying to chase the requirements of half a dozen different editors is silly.

This is how I see it. The more contributors you have with a code base, the larger the possibility that one person will mistakenly commit something that could have easily been avoided by just preemptively adding it to the .gitignore.

You cant preempt every file or folder, but its almost no effort to catch the obvious ones.

This is how I see it. The more contributors you have with a code base, the larger the possibility that at least one person will mistakenly commit something that could have easily been avoided by just preemptively adding it to the project .gitignore.

You cant prompt every file or folder, but its almost no effort to catch the obvious ones.

Yeap. To reduce pain, you need to work with reality rather than ideals. If you work with a big group, you either add a few lines into your gitignore, or you write code to check for those very same files in your CI/PR system, because you're tired of reversing commits and rejecting PRs because you're the only one that cares about a few extra files.

I’m not sure kindness is the best framing. At least, not in terms of being nice to any particular person who might commit unwanted files by mistake.

It’s one of several tools a project can use to ensure quality, alongside eg linters and formatters. Automating those (in this case by defaulting to the expected outcome) reduces friction on basically every operation anyone might do in a project, in any context.

Through the lens of kindness, it benefits you as well as your team… and ultimately everyone else downstream, since you’re all not wasting time and cognitive load on trivially preventable mistakes.

In my opinion (which might not be shared by everyone) this is a you problem. Developers in the team not using decontainers should not have to worry about your environment. ide/local-env stuff should be ignored in the users git setup, everything that the repo creates (build artifacts, environment files etc) should be in the repo.

Interesting case. For the global ignore file, couldn't you just bind-mount that into the container?

That's an interesting case, where you are crossing operating systems.

---

That said, the easier change is still a one/two line bind mount that trying to exhaustively list ignored directories for every IDE or tool under the sun.