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.
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.
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.
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)
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.
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.
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.
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 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.
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.
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.
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?
~/.config/git/ignore and ~/.config/git/config is the proper place for your global git config and ignore instead of creating a ~/.gitignore_global and changing the config. IMO.
my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things.
the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.
Absolutely. On that subject, I prefer the Atlassian method for storing dotfiles in git but sometimes I feel like it's Mootools vs jQuery all over again.
Wow! How did I not know this? I am a professional software dev for 20 years… and only ever used .gitignore !
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…
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.
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?
I use the ever living hell out of .git/info/exclude. Works great for scripts/Makefiles I only want locally and collaborators wouldn’t care about or be able to use.
For quite a while, I've have had a shell fcn that will take all the untracked files listed in a git status, and push them to .git/info/exclude. Generally applied after an add+commit of everything I do want to go generally into the repo.
Usually when I'm working in one part of the codebase and I have sample data or something at a specific path on my local machine and Im testing the same thing over and over again will I make a Makefile or something and info/exclude it to help me keep focused. That's one way I use it.
One point of clarification: with git, "global" means per-user, not "machine-wide. (I never understood why "--global" wasn't better named, maybe "--user".) That's why these pathnames are in a user's home (the "~" means the current user's home directory).
Machine-wide configuration is called "system" in git, and generally lives under "/etc".
Magit has good support for these other methods. You press <i> and then select if you want the ignore to be shared (.gitignore) or private (.git/info/exclude).
allows for remote specific configs, overriding say email or other required options depending on where you send contributions - without having to have per repo config
works for dir too
[includeIf "gitdir:/home/user/src/work1/"]
Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slash
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.
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.
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.
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)
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.
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.
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.
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 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.
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?
> However, that's an extra script or devcontainer mounts config over a gitignore line.
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.
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?
.DS_Store
~/.config/git/ignore and ~/.config/git/config is the proper place for your global git config and ignore instead of creating a ~/.gitignore_global and changing the config. IMO.
my dotfiles are a lot smaller at the root level taking advantage of the ~/.config/ for a lot more things.
the git exclude isn't used as much because it doesn't get committed to the repository so you'd have to recreate it each time you wanted to use it. that doesn't mean they're bad just why they are not used.
As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
Absolutely. On that subject, I prefer the Atlassian method for storing dotfiles in git but sometimes I feel like it's Mootools vs jQuery all over again.
Wow! How did I not know this? I am a professional software dev for 20 years… and only ever used .gitignore !
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 :-)
Not sure where I picked up this, but I’ve added this to my global Git ignore:
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.mine's `scratch/`
hasn't tripped me up (yet)
Mine is
and I hide it by putting a .gitignore in it that just contains am asterisk (*), nothing else, that way it ignores itself and anything in it.Does Windows still go crazy when making an “aux” or “con” directory or has this been patched?
Genius idea.
The next Elon musk.
I do this too! But I call it `.local`
I have a new-repository script that creates a .local directory and puts a .gitignore with just `*` in it.
Doesn't git automatically exclude all files starting with a dot?
No
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?
I use the ever living hell out of .git/info/exclude. Works great for scripts/Makefiles I only want locally and collaborators wouldn’t care about or be able to use.
For quite a while, I've have had a shell fcn that will take all the untracked files listed in a git status, and push them to .git/info/exclude. Generally applied after an add+commit of everything I do want to go generally into the repo.
Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?
Usually when I'm working in one part of the codebase and I have sample data or something at a specific path on my local machine and Im testing the same thing over and over again will I make a Makefile or something and info/exclude it to help me keep focused. That's one way I use it.
Yeah this is pretty much it.
One point of clarification: with git, "global" means per-user, not "machine-wide. (I never understood why "--global" wasn't better named, maybe "--user".) That's why these pathnames are in a user's home (the "~" means the current user's home directory).
Machine-wide configuration is called "system" in git, and generally lives under "/etc".
This is just a very low-effort regurgitation of this: https://git-scm.com/docs/gitignore
Submit that link to Hacker News, and see how far it gets!
Hey, come on now - they added 'check-ignore' which is good complementary advice.
You made my day. Everything is said and explained there.
Ok, sometimes a more vivid and visually explanatory style would help, but here still Google is your friend for individual concepts.
One of the best resources there is. git is a hell of a tool. It looks simple but is so beautifully versatile without being complex or not deductive.
What part of
don't you understand?!Well, since I know what a delta is, and I know what an object is, I understand all of it.
Congratulations!
"Google is your friend for individual concepts."
Asking aLlm is the new google
I knew about .git/info/exclude and ~/.config/git/ignore but not about git-check-ignore(1). Neat!
git is so incredible, it never ceases to amaze me, what a timeless piece of software
I still like using gitignore very much
Magit has good support for these other methods. You press <i> and then select if you want the ignore to be shared (.gitignore) or private (.git/info/exclude).
Exclude sounds like a recipe for sadness.
these are great for ignoring files by name, but you often want to ignore binary files or other files by type.
Set a global hooks dir, and then block binary files in pre-commit by using file or checking the git index
Or block large changes, because binary mods are often larger than a real diff.another useful snippet
allows for remote specific configs, overriding say email or other required options depending on where you send contributions - without having to have per repo configworks for dir too
Git is REAL bitch about exact syntax here; the first snippet won't work with just :*, it needs :/* ; the second won't work without trailing slashNot really news. I worked with dozens of developers who have managed to ignore files in Git.