51–60 of 188 posts
Earlier quoted context omitted.
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.
Interesting case. For the global ignore file, couldn't you just bind-mount that into the container?
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 p…
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.
---
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.
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 p…
Re: per-user ignores: > For example, if you’re on macOS, adding .DS_Store here would be ideal. As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
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 p…
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.
I just realized that I never even „asked“ myself if there might exist a better way than to clutter .gitignore with all kinds of specific excluded only relevant to me. I just accepted the world as it appeared to me…
And Today, it got s little bit better :-)
Re: per-user ignores: > For example, if you’re on macOS, adding .DS_Store here would be ideal. As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?
Re: per-user ignores: > For example, if you’re on macOS, adding .DS_Store here would be ideal. As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?
Not sure where I picked up this, but I’ve added this to my global Git ignore: attic That way you can just create an attic directory in any project where you can keep random stuff that should never be committed. I’ve yet to find a repo which actually has such a directory checker in.
hasn't tripped me up (yet)
Re: per-user ignores: > For example, if you’re on macOS, adding .DS_Store here would be ideal. As long as every Mac user on your project does. If you have more than one, it may be better off taken out of everyone's hands.
That's a very particular way to frame the few vs the many. If a single macOS user works on ten different projects, should all ten projects add that line, or may things be better off taken out of each project's hands and on that single user?