Is this right? These tools don't show ignored files because they aren't part of the repository. If a now-ignored file has made it into the repository, surely you want to see it?
Doing it the other way around is also possible but harder as the git client will refuse but can be convinced.
They will show the files in your repo.
gitignore just decides whether untracked files appear as new or ignored. (But you can commit them anyway if you are so inclined.)
git rm --cached <file>(shrug)
Useful when you want to create a temporary file to help you e.g. with a bug investigation, and make sure it stays untouched while you switch branches, and to avoid accidentally committing it.
I have a shell alias like this:
git-ignore-local () {
echo "$1" >> .git/info/exclude
}
and use it like `git-ignore-local myfile.ext` git-ignore-local () {
root=$(git rev-parse --show-toplevel)
path=$(readlink -f "$1")
# ${path#${root}} should suffice if you don't have realpath
relpath=$(relpath -m --relative-to="$root" "$path")
echo "$relpath" >> "${root}.git/info/exclude"
}
Edit: You could also put the function contents as an executable on your PATH called `git-ignore-local` then it becomes something you can invoke as `git ignore-local`.- in root of the repo, it prints empty string
- if you're 1 level deep it prints `../`
- if you're 2 levels deep it prints `../../`
One minor drawback: inside `.git` subfolder, it always prints empty string too.
News to me and a lot of people.
I see a lot of .DS_Store in a lot of gitignore.
DS_Store files are just annoying, but I've seen whole bin and obj directories, various IDE directories, and all kinds of other stuff committed by people who only know git basics. I've spent way more effort over time cleaning up than I have on adding a comprehensive gitignore file.
It takes practically no effort to include common exclude patterns and avoid all that. Personally, I just grab a gitignore file from GitHub and make a few tweaks here and there:
curl -fsSL https://www.toptal.com/developers/gitignore/api/linux > ~/.gitignore
git config --global core.excludesFile ~/.gitignoreIMO, it's best to keep things that are "your fault" (e.g. produced by your editor or OS) in your global gitignore, and only put things that are "the repository's fault" (e.g. build artifacts, test coverage reports) in the repository's gitignore file.
I haven't checked if there's a way to maintain a project-scoped _personal_ `.vscode` for those idiosyncratic settings or extensions you want applied to only this project but wouldn't be appropriate to foist on everyone else. I hope there is.
Very well put. This should be in the git-ignore manpage.
It catches me out when something's ignored I don't expect, and it's not clear why in the working directory/repo, only for me to remember about the global one.
It catches others out (or catches me out by their doing) in collaboration when say I've not committed something, not even really been aware of the potential hazard, and that's been desired; but then someone else comes along and `git commit -a`s it.
But then where it is particularly useful is myriad tools that fall back on git ignore in lieu of (or in addition to) their own ignore files...
At the moment I'm making do with aliasing `git clean -e .jj`
Just in case it's unclear, you'd then set an excludesFile in the included file to the path to a file like jj.gitignore that has a line like .jj in it.
This is not true, .mailmap is [unfortunately] not supported by GitHub: https://github.com/orgs/community/discussions/22518
If you configure your git client to use it, git blame will fail in any repository in which one is not present.
This strikes me as a bad idea. Which side of the merge is “ours” and which ond is “theirs” during merges or rebases is something of a crapshoot[1], so this kind of setting only makes sense when merge conflicts are only ever discovered and resolved by automatic tooling (e.g. the git-annex branch[2] in git-annex-enabled repos).
[1] https://stackoverflow.com/questions/25576415/what-is-the-pre...
/test export-ignore
That means that when a "git export" happens from git to our production server it skips all test files. (In our case Capistrano does that, no additional configuration needed.) You never want test files on a production server and it saves disk space to boot. Normal usage is not affected, in development or testing you would always do a "git pull" or similar.
There is also export-subst that is also used by git archive to create an output similar to git describe directly in a file.
Most mentions I see of `core.excludesFile` refer to it as a global, but it could also be a local file. I use it as a local file since for some projects I'm working on I end up having a set of scripts/logs/anything specific to the repository that I don't want to be in the `.gitignore`.
https://nesbitt.io/2026/02/12/the-many-flavors-of-ignore-fil...