Hey, come on now - they added 'check-ignore' which is good complementary advice.
_the_inflator•Jun 18, 2026
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.
y2244•Jun 18, 2026
"Google is your friend for individual concepts."
Asking aLlm is the new google
b40d-48b2-979e•Jun 18, 2026
git is a hell of a tool. It looks simple but is so beautifully versatile without being complex
without being complex
Uh, what?
rafram•Jun 18, 2026
What part of
Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 10 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.43 KiB | 1.43 MiB/s, done.
Total 8 (delta 7), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
don't you understand?!
onraglanroad•Jun 18, 2026
Well, since I know what a delta is, and I know what an object is, I understand all of it.
rafram•Jun 18, 2026
Congratulations!
axus•Jun 18, 2026
Submit that link to Hacker News, and see how far it gets!
bryancoxwell•Jun 18, 2026
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.
RSHEPP•Jun 18, 2026
Interested in examples of the types of scripts others collaborators wouldn't be able to use? Like scripts for PR workflows?
junon•Jun 18, 2026
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.
bryancoxwell•Jun 18, 2026
Yeah this is pretty much it.
digikata•Jun 18, 2026
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.
hk1337•Jun 18, 2026
~/.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.
b40d-48b2-979e•Jun 18, 2026
As a bonus, you can (should?) version control your `~/.config` dir to enable future revisions and sharing.
hk1337•Jun 18, 2026
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.
judofyr•Jun 18, 2026
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.
williamjackson•Jun 18, 2026
I do this too! But I call it `.local`
zahlman•Jun 18, 2026
I have a new-repository script that creates a .local directory and puts a .gitignore with just `*` in it.
bflesch•Jun 18, 2026
Doesn't git automatically exclude all files starting with a dot?
micael_dias•Jun 18, 2026
No
weinzierl•Jun 18, 2026
Mine is
aux
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.
metadat•Jun 18, 2026
Genius idea.
bitvvip•Jun 18, 2026
I still like using gitignore very much
jeremyscanvic•Jun 18, 2026
I knew about .git/info/exclude and ~/.config/git/ignore but not about git-check-ignore(1). Neat!
barbazoo•Jun 18, 2026
Exclude sounds like a recipe for sadness.
wpollock•Jun 18, 2026
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".
globular-toast•Jun 18, 2026
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).
uptown•Jun 18, 2026
Not really news. I worked with dozens of developers who have managed to ignore files in Git.
kevincox•Jun 18, 2026
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•Jun 18, 2026
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•Jun 18, 2026
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.
Anon1096•Jun 18, 2026
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.
dofm•Jun 18, 2026
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.
tonymet•Jun 18, 2026
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
13 Comments
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.
Asking aLlm is the new google
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.
Machine-wide configuration is called "system" in git, and generally lives under "/etc".
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.
In the future, I think I might just be less nice about it. I dunno.
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.
> 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.
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.