> GitHub, GitLab, and Gitea all respect .gitignore and won’t show ignored files in the web UI
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?
`git add -f` will add ignored files. Once you've done that, any files you've added will be part of your commit regardless of the contents of .gitignore.
Since using jj I'm on the lookout for some kind of setting that will exclude the .jj folder from the repo _and_ any operation including git clean, without having to add it to the repo. I.e., make it completely invisible to git including `git clean -xdf`!
At the moment I'm making do with aliasing `git clean -e .jj`
I'd like to emphasize the `.git/info/exclude`, which is a "repo-local gitignore", i.e. only for you and only for this repo.
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.
This is a well put together list. One thing that frustrates me is that not all tooling respects mailmap. IntelliJ has an open feature/bug request for integrating mailmap into its git functionality. Additionally, the .git-blame-ignore-revs is more of a convention because you still have to manually configure that to be the file name to use.
If you have someone in the team that can't maintain proper source code hygiene, you kind of have to resort to their inclusion in the project gitignore.
You still want to put these kinds of things in every project where you are collaborating. You can't depend on everyone to know and do this, so best to just be prepared for those who don't.
More importantly, it avoids the issue where every new editor requires an addition to every repository's gitignore file (.idea, .vscode, etc).
IMO, 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.
> IMO, 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.
Very well put. This should be in the git-ignore manpage.
I have mixed feelings about it really, I am aware of it, and use it in my dot files, but I think it's quite a gotcha - just recently actually I've been thinking to remove it.
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...
> GitHub, GitLab, and Gitea all respect .gitignore and won’t show ignored files in the web UI
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?
Not true, you can push a file and later gitignore it and it will remain visible on those UIs. It's still part of the repo.
Doing it the other way around is also possible but harder as the git client will refuse but can be convinced.
Yeah this is wrong.
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.)
how do you commit a file without first adding it?
`git add -f` will add ignored files. Once you've done that, any files you've added will be part of your commit regardless of the contents of .gitignore.
Right... and also (I think; unsure bc I only ever use cli) some GUIs (eg github.com web ui) may enable adding files that'd otherwise be ignored.
(shrug)
Yeah, also that's probably not the kind of error a human writing this post would make... I stopped reading at that point
This is exactly the sort of error that a human with a slightly incorrect mental model for something makes all the time.
Since using jj I'm on the lookout for some kind of setting that will exclude the .jj folder from the repo _and_ any operation including git clean, without having to add it to the repo. I.e., make it completely invisible to git including `git clean -xdf`!
At the moment I'm making do with aliasing `git clean -e .jj`
.git/info/exclude
.git-blame-ignore-revs, while great, unfortunately belongs in the “Other Conventions” section.
If you configure your git client to use it, git blame will fail in any repository in which one is not present.
As of git 2.52, it's possible to use (:optional) to avoid errors in repositories that don't have this file https://stackoverflow.com/a/79824780
> GitHub’s contributor graphs use mailmap.
This is not true, .mailmap is [unfortunately] not supported by GitHub: https://github.com/orgs/community/discussions/22518
I'd like to emphasize the `.git/info/exclude`, which is a "repo-local gitignore", i.e. only for you and only for this repo.
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:
and use it like `git-ignore-local myfile.ext`.git/info/exclude is mentioned in the first section (about .gitignore)
Oops, I've glanced over it too fast. Thanks - updated my post.
This is a well put together list. One thing that frustrates me is that not all tooling respects mailmap. IntelliJ has an open feature/bug request for integrating mailmap into its git functionality. Additionally, the .git-blame-ignore-revs is more of a convention because you still have to manually configure that to be the file name to use.
For a deeper dive on git ignore files, see:
https://nesbitt.io/2026/02/12/the-many-flavors-of-ignore-fil...
> Global ignores are good for OS-specific files like .DS_Store or Thumbs.db that shouldn’t clutter every project’s .gitignore.
News to me and a lot of people.
I see a lot of .DS_Store in a lot of gitignore.
If you have someone in the team that can't maintain proper source code hygiene, you kind of have to resort to their inclusion in the project gitignore.
You still want to put these kinds of things in every project where you are collaborating. You can't depend on everyone to know and do this, so best to just be prepared for those who don't.
I'd prefer to leave them out. That way I can see who's not paying attention when they make commits and are just doing `git commit -a -m "yolo"`.
I have this two liner as part of my post-os-install setup script:
Assuming your global config is ~/.config/git/config, you can download it to ~/.config/git/ignore and not need the overriding explicit excludesFile.
Huh, TIL
More importantly, it avoids the issue where every new editor requires an addition to every repository's gitignore file (.idea, .vscode, etc).
IMO, 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.
> IMO, 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.
Very well put. This should be in the git-ignore manpage.
I have mixed feelings about it really, I am aware of it, and use it in my dot files, but I think it's quite a gotcha - just recently actually I've been thinking to remove it.
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...