An ignore rule that lives only in the clone's own exclude file does not travel, so a file ignored on one machine is untracked on the next

The lesson

"This file is ignored" is a statement about one machine unless you have checked where the rule comes from. Version control accepts ignore rules from the committed ignore file, from a per-clone exclude file inside the repository metadata, and from a per-user global excludes file. All three produce the same observable result: the file never appears in status. Only the committed one travels with a clone.

The two local sources accumulate quietly. An editor or tool adds an entry to the per-clone exclude file on first run, or someone adds one there by hand to avoid touching a shared file, and from then on the machine behaves as though the repository ignores it. Every signal available on that machine confirms it, so nobody has reason to check again.

The gap only matters the moment something else writes that file — a second machine, a CI runner, a setup script — and that is exactly when it bites, because such a file is typically per-machine by design: local paths, local credentials, local switches. Untracked on the new clone, it is one broad add away from being committed and then pulled back over the original machine's copy.

The failure that taught it

A setup script was being written to prepare a second machine: among other things it wrote a per-machine editor settings file that must never be committed. On the machine where the script was written, that file had always been invisible to status, so it was assumed to be ignored.

The script was tested by running it inside a fresh clone in a scratch directory rather than in the working checkout. There the settings file showed as untracked. Asking version control where the original machine's ignore came from named the per-clone exclude file, not the committed ignore file — a rule the fresh clone, and the real second machine, would never have had. The fix was one line in the committed ignore file. Without the fresh-clone test, the first sign would have been the second machine's local paths arriving in a pull.

How to apply it

• Before relying on a file being ignored for anything another machine will write, ask where the rule comes from: git check-ignore -v <path> prints the source file and line. Accept only the committed ignore file; a per-clone exclude or a global excludes file is a property of your machine, not of the repository.
• Test any setup script for a new machine in a fresh clone, not the checkout you developed it in. The checkout carries every local exclude, cached credential and untracked file the new machine lacks, so it cannot show you what the new machine will see.
• When a tool writes a per-machine file, put its ignore rule in the same change as the tool, in the committed ignore file, with a comment saying which tool writes it.