Where should Git ignore rules for editor and OS files live instead of the repo .gitignore?

## The four sources For any given untracked path, Git consults, in decreasing order of precedence: 1. **Patterns supplied on the command line**, for commands that accept them. 2. **`.gitignore` files** in the path's own directory and every parent up to the top of the work tree, with files closer to the path overriding files further up. 3. **`$GIT_DIR/info/exclude`**, normally `.git/info/exclude`, which lives inside the repository directory and is never transferred by clone, fetch or push. 4. **The file named by `core.excludesFile`**, the per-user global list. If the setting is unset, Git uses `$XDG_CONFIG_HOME/git/ignore`, falling back to `$HOME/.config/git/ignore`. Within each source the last matching line still wins; the ordering above resolves conflicts *between* sources. ## Which rule goes where The deciding question is: who else produces this file? - **Everyone who builds the project** produces `target/`, `node_modules/`, `*.pyc`, coverage reports. These belong in the committed `.gitignore`, close to where they are generated. Reviewers can see them, and a new contributor gets them for free. - **Only you** produce `.idea/`, `.vscode/`, `.DS_Store`, swap files, and directories your particular editor drops everywhere. These belong in your global excludes file. Putting them in the repository is a small tax on everyone: the file grows a section for every tool anyone has ever used, and the list quietly becomes unmaintainable. - **Only you, and only here**, covers a `scratch/` directory or a local profiling dump in one clone. That is what `.git/info/exclude` is for. It is invisible to everyone else and disappears if you delete the clone, which is exactly the intended lifetime. ## Why precedence matters in practice Because the repository's `.gitignore` outranks both personal sources, a project can override an over-broad personal rule. If a developer globally ignores `*.log` and the project genuinely tracks a fixture named `sample.log`, the repository file can re-include it with `!sample.log`. The reverse is not possible: a personal file cannot override the project. This asymmetry is deliberate. Shared correctness beats personal convenience, and it means a project can be made self-consistent regardless of who checks it out. ## The failure mode this prevents The common pathology is a repository `.gitignore` that has grown into a catalogue of editors, operating systems and personal tools, contributed to by everyone who ever joined. Nobody dares delete a line because nobody knows who needs it, and the broad patterns inside it eventually hide a real source file. Splitting by ownership keeps the shared file short enough to read in one screen and to reason about during review. ## Diagnosing across sources When a file behaves differently on two machines, the usual culprit is a personal rule. `git check-ignore -v <path>` prints the source file for the deciding rule, so it names the global file or `.git/info/exclude` explicitly. That single command distinguishes "the project hides this" from "your machine hides this", which is exactly the ambiguity that wastes time in a debugging session. ## Operational notes - `.git/info/exclude` is not backed up and not transferred; treat it as scratch, not as configuration you rely on. - Setting `core.excludesFile` is a per-user config change, so it can be set at global scope once and applies to every repository you clone afterwards. - Automation that checks out the repository fresh sees only the committed rules. If a build step depends on something being ignored, that rule must be in the repository, not in anyone's personal file. - Because ignore rules never apply to tracked paths, moving a rule between sources changes nothing for files already in the index; those still need untracking.