Local-Only Excludes with .git/info/exclude

4 min read.
Tags: gitgitignorelocal-config

Sometimes you have files that only matter on your machine: editor settings, scratch notes, AI context files, one-off scripts. They do not belong in .gitignore because the rest of the team does not need the rule. They also should not show up every time you run git status.

Use .git/info/exclude for that. It is a per-repository ignore file that lives inside .git, so Git uses it locally but never commits it.

Quick answer

Add your local-only pattern to .git/info/exclude:

printf '%s\n' 'AGENTS.local.md' >> .git/info/exclude

Verify Git is ignoring the file:

git check-ignore -v -- AGENTS.local.md

Expected output looks like this:

.git/info/exclude:7:AGENTS.local.md	AGENTS.local.md

Your line number may differ. The important part is that Git says the rule came from .git/info/exclude.

The 3 git ignore mechanisms

Git has three common places for ignore rules.

Use .gitignore when the rule belongs to the project. Examples: node_modules/, build output, generated files, and local env files that nobody should commit. This file is versioned, so every clone gets the same ignore rules.

Use core.excludesFile when the rule belongs to your machine across many repos. Examples: .DS_Store, temporary editor files, or personal tool output that follows you everywhere. Configure it once:

git config --global core.excludesFile ~/.config/git/ignore

Then put patterns in that file.

Use .git/info/exclude when the rule is personal but only for this repo. That is the useful middle ground. It does not affect teammates, and it does not leak into every repo you work on.

When to use .git/info/exclude

Use .git/info/exclude for files that are local to one checkout:

  • scratch notes for this project
  • personal AI context files
  • editor settings you do not want to share
  • local scripts that help you debug this repo
  • temporary exports or command outputs

A good test: if the file is useful only to you and only in this repository, put it in .git/info/exclude.

For example:

# Personal notes and local assistant context
scratch.md
AGENTS.local.md
.claude/local/

This keeps git status clean without making the repo's .gitignore carry your private workflow.

Do not use it for team rules

If everyone should ignore the same file, commit the rule in .gitignore.

A local exclude is invisible to other clones. That is the whole point. It also means it is the wrong place for shared project behavior. If your build creates dist/, or your test runner creates coverage/, the ignore rule should usually be in .gitignore so new contributors do not have to rediscover it.

The split is simple:

  • project-generated file: .gitignore
  • every-repo personal file: core.excludesFile
  • this-repo personal file: .git/info/exclude

The easy typo

The path is easy to flip in your head. It is not this:

.git/exclude/info

It is this:

.git/info/exclude

If you only remember one command, use this shape:

printf '%s\n' '<pattern>' >> .git/info/exclude

That path already exists in every Git repository. You should not need to create it.

Verify the rule

After adding a pattern, run:

git check-ignore -v -- <file>

Example:

git check-ignore -v -- AGENTS.local.md

If the file is ignored, Git prints the matching rule and where it came from:

.git/info/exclude:7:AGENTS.local.md	AGENTS.local.md

If you get no output, Git did not match any ignore rule. Check the path, the pattern, and the spelling of .git/info/exclude.

You can also inspect status with ignored files shown:

git status --ignored --short

Ignored files appear with !!.

If the file is already tracked

Ignore rules only apply to untracked files. If Git already tracks the file, adding it to .git/info/exclude will not hide later changes.

Check whether Git tracks it:

git ls-files -- AGENTS.local.md

If that prints the file path, Git is tracking it.

For a file that should stop being tracked by the repo, remove it from the index without deleting your local copy:

git rm --cached AGENTS.local.md

Then commit that change if it is really a repository cleanup. Be careful here: removing a tracked file affects everyone after they pull. For purely personal files, the better fix is usually to avoid committing them in the first place, then add the local pattern to .git/info/exclude.

This is not secret management

Ignore rules help you avoid accidental commits. They do not make a file safe.

If a file contains credentials, keep it out of logs, issue comments, AI prompts, and shared backups too. For project env files, the usual pattern is to commit an example like .env.example, ignore the real .env, and load secrets from your local machine or deployment platform.

Conclusion

Use .git/info/exclude for per-repo files that only matter on your machine. Use .gitignore for shared project rules. Use core.excludesFile for personal rules that apply across all repos.

When in doubt, add the pattern locally and verify it:

printf '%s\n' 'AGENTS.local.md' >> .git/info/exclude
git check-ignore -v -- AGENTS.local.md
Related Posts