.gitignore Isn't the only way to ignore files in Git

Hendrikto

This is just a very low-effort regurgitation of this: https://git-scm.com/docs/gitignore

bryancoxwell

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.

hk1337

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

judofyr

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.

bitvvip

I still like using gitignore very much

jeremyscanvic

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

barbazoo

Exclude sounds like a recipe for sadness.

wpollock

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

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

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

kevincox

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.

dofm

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

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.

PunchyHamster

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

hmokiguess

git is so incredible, it never ceases to amaze me, what a timeless piece of software

lmf4lol

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

hungryhobbit

Fun article, but it leaves out my favorite "almost ignore" feature in Git: `.gitattributes`. This file lets you specify that git should "ignore" the diff from certain files. For instance, Node projects have a `package-lock.json` that is pure noise from a Git standpoint (it's just massive amounts of diff specifying specific versions of libraries, and the real human-readable version is in a separate `package.json` file). With `.gitattributes` in the root of your project, you can just add a line: `package-lock.json -diff` Now, that file will still get staged/committed (which you want) ... but when you `git diff` you won't see the massive amounts of pointless diff in that file.

leleat

There is also git update-index --[no]-skip-worktree for files that are already tracked. This can be useful for some local experimentation... it's just a bit annoying to use because it's not really surfaced anywhere by git (kinda). You need to remember that you set it; otherwise other operations like checkouts may be blocked.

elyobo

Relatedly, some aliases I have in place. assume = update-index --assume-unchanged unassume = update-index --no-assume-unchanged assumed = "!git ls-files -v | grep ^h | cut -c 3-" unassumeall = "!git assumed | xargs git update-index --no-assume-unchanged" assumeall = "!git st -s | awk {'print $2'} | xargs git assume"

andrelaszlo

Here's how I use the excludes file to set a different config for a project directory containing multiple repos: https://laszlo.nu/blog/project-level-git-config.html