5 ms·

The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to ever

The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet. My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.

wccrawford 4mo ago
I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain. In the future, I think I might just be less nice about it. I dunno.
- eyelidlessness 4mo ago
  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.
- nomel 4mo ago
  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.
- xboxnolifes 4mo ago
  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.
- xboxnolifes 4mo ago
  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.
Anon1096 4mo ago
You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.
- mikepurvis 4mo ago
  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.
  - ffsm8 4mo ago
    That's the thing though, you don't need to do that. Whoever is using whatever editor can do it, so the effort is distributed to whoever cares to contribute. There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore. (I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)
    - antonvs 4mo ago
      The penalty is a long file full of cruft that's effectively impossible to ever clean up.
- kodablah 4mo ago
  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.
  - deleted 4mo ago
8cvor6j844qw_d6 4mo ago
I prefer gitignore since it survives dev container rebuilds. I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.
- mvanbaak 4mo ago
  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.
- arcanemachiner 4mo ago
  Interesting case. For the global ignore file, couldn't you just bind-mount that into the container?
  - paulddraper 4mo ago
    > However, that's an extra script or devcontainer mounts config over a gitignore line.
    - arcanemachiner 4mo ago
      Well, that's what I get for being an idiot.
- paulddraper 4mo ago
  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.
paulddraper 4mo ago
.DS_Store
- aendruk 4mo ago
  My computer doesn’t make .DS_Store files. If yours does, it’s your responsibility to not litter the codebase with them. Corollary: My computer does make other kinds of files, and you’d never know it.
  - paulddraper 4mo ago
    I agree.
mvdtnz 4mo ago
Do you not see the conflict between seeing the same incorrect behaviour again and again, and having a firm rule that expressly forbids the easiest fix to that behaviour?
- dofm 4mo ago
  I am getting the impression that people both see and enjoy the conflict. :-/
mjmas 4mo ago
Or if your editor is happy to store them in a subfolder that is useful. I use Sublime with the AutoProjects extension and it puts .sublime-project snd .sublime-workspace under a .sublime folder that I can have a .gitignore * underneath.
kortex 4mo ago
I'd rather have a pristine repo (no .ds_store/.idea/etc) than a pristine .gitignore file.
- superb_dev 4mo ago
  Well you still ignore those things, just not with a committed .gitignore. Now your repo and your gitignore are pristine

wccrawford 4mo ago

I've always added it to the project's gitignore because I want to make sure nobody else adds those to the project, either, out of ignorance. I'm mainly doing it out of kindness to them, because I am definitely removing them from git again and it's going to cause them some pain. In the future, I think I might just be less nice about it. I dunno.

eyelidlessness 4mo ago
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.
nomel 4mo ago
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.
xboxnolifes 4mo ago
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.
xboxnolifes 4mo ago
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.

Anon1096 4mo ago

You frequently having to tell people about a global configuration gitignore is an obvious consequence of "My general rule is that in-repo .gitignore should only be used for repo-specific things". It wastes less of everyone's time to just gitignore them in every project.

mikepurvis 4mo ago
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.
- ffsm8 4mo ago
  That's the thing though, you don't need to do that. Whoever is using whatever editor can do it, so the effort is distributed to whoever cares to contribute. There is no meaningful penalty for it to be not up-to-date. There is only a benefit for people who come in when it's already configured, as they don't need to configure anything anymore. (I say that but I'm using a global ignore too for eg ai configuration like skills as I like to half-ass them before discarding again)
  - antonvs 4mo ago
    The penalty is a long file full of cruft that's effectively impossible to ever clean up.
kodablah 4mo ago
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.
- deleted 4mo ago

8cvor6j844qw_d6 4mo ago

I prefer gitignore since it survives dev container rebuilds. I can set a creation script or volume to restore/persist configs if I must avoid gitignore. However, that's an extra script or devcontainer mounts config over a gitignore line.

mvanbaak 4mo ago
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.
arcanemachiner 4mo ago
Interesting case. For the global ignore file, couldn't you just bind-mount that into the container?
- paulddraper 4mo ago
  > However, that's an extra script or devcontainer mounts config over a gitignore line.
  - arcanemachiner 4mo ago
    Well, that's what I get for being an idiot.
paulddraper 4mo ago
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.

paulddraper 4mo ago

.DS_Store

aendruk 4mo ago
My computer doesn’t make .DS_Store files. If yours does, it’s your responsibility to not litter the codebase with them. Corollary: My computer does make other kinds of files, and you’d never know it.
- paulddraper 4mo ago
  I agree.

mvdtnz 4mo ago

Do you not see the conflict between seeing the same incorrect behaviour again and again, and having a firm rule that expressly forbids the easiest fix to that behaviour?

dofm 4mo ago
I am getting the impression that people both see and enjoy the conflict. :-/

mjmas 4mo ago

Or if your editor is happy to store them in a subfolder that is useful. I use Sublime with the AutoProjects extension and it puts .sublime-project snd .sublime-workspace under a .sublime folder that I can have a .gitignore * underneath.

kortex 4mo ago

I'd rather have a pristine repo (no .ds_store/.idea/etc) than a pristine .gitignore file.

superb_dev 4mo ago
Well you still ignore those things, just not with a committed .gitignore. Now your repo and your gitignore are pristine