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.

~/.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.

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.

    aux

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.

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.

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

    git is a hell of a tool. It looks simple but is so beautifully versatile without being complex

    without being complex

   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.

I knew about .git/info/exclude and ~/.config/git/ignore but not about git-check-ignore(1). Neat!

Exclude sounds like a recipe for sadness.

I still like using gitignore very much

Not really news. I worked with dozens of developers who have managed to ignore files in Git.

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

   git config --global core.hooksPath ~/.config/git/hooks

Or block large changes, because binary mods are often larger than a real diff.

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).

another useful snippet

    [includeIf "hasconfig:remote.*.url:git@git.company.com:*/**"]
    path = /home/dir/per/company/config

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