HN Debrief

.gitignore Isn't the only way to ignore files in Git

  • Developer Tools
  • Programming
  • Open Source

The post is a practical Git refresher. It points out that `.gitignore` is only one layer in Git’s ignore system, then introduces two others that many developers never use: `.git/info/exclude` for local ignore rules that stay inside one clone, and a per-user global ignore file under Git config for personal editor, OS, and tooling junk. It also highlights `git check-ignore` as the command to explain why a file is being ignored. That landed as the most useful part for many readers, not because the mechanics are obscure in the docs, but because teams routinely keep solving the wrong problem by stuffing every personal artifact into shared `.gitignore` files.

If your repos keep accumulating editor, OS, and local tooling junk, move that policy into per-user ignores and reserve `.gitignore` for files the project itself creates. Also teach people `git check-ignore` and the difference between shared, local, and per-user ignore scopes, because that alone cuts a lot of low-value review churn.

Discussion mood

Positive about the Git features and slightly exasperated about how often teams misuse `.gitignore`. The main friction came from a familiar culture split between keeping repos pristine with per-user config and being pragmatic by adding obvious junk to shared ignores so contributors stop committing it.

Key insights

  1. 01

    Keep personal tool junk out of repos

    Using Git’s per-user ignore file for editor, OS, and one-off tool artifacts keeps shared `.gitignore` focused on files the project itself produces. That reduces long-lived clutter, avoids endless additions for every contributor’s setup, and gives maintainers a clean rule they can teach once instead of re-litigating in every repo.

    Write down a simple team policy: repo ignores for project artifacts, user ignores for personal environment files. Add onboarding instructions for the global ignore file so people stop solving personal setup problems in shared code.

      Attribution:
    • kevincox #1
    • kodablah #1
    • saagarjha #1
    • antonvs #1
    • WCSTombs #1
  2. 02

    Lockfile diffs are worth reading

    Suppressing diffs for tracked lockfiles looks attractive when the output is huge, but it cuts out the exact place where transitive dependency changes become visible. Several people tied that directly to supply-chain review, dependency forensics, and catching unexpected bumps before they land, which makes `package-lock.json` and `uv.lock` bad candidates for blanket `-diff` rules.

    Do not hide lockfile diffs by default. If review noise is the problem, tighten your dependency update workflow or use better diff tooling rather than removing visibility.

      Attribution:
    • hungryhobbit #1
    • po1nt #1
    • selcuka #1
    • jeromegv #1
    • phinnaeus #1
    • rtpg #1
  3. 03

    Git has multiple ignore-like scopes

    The useful mental model is not just shared versus ignored. Git has separate scopes for untracked local junk, per-user defaults, and tracked files you want to stop noticing locally. Comments called out `skip-worktree`, `assume-unchanged`, and the distinction between user-level `--global` config and true system-wide config under `/etc`, which helps explain why developers keep reaching for the wrong mechanism.

    Teach the scopes, not just the commands. When someone asks to “ignore a file,” first decide whether the file is untracked, tracked, repo-specific, or local-only before choosing the mechanism.

      Attribution:
    • leleat #1
    • elyobo #1
    • wpollock #1
    • lmf4lol #1
  4. 04

    A throwaway local directory works well

    Several people use a globally ignored directory like `attic`, `.local`, `scratch`, or `aux` inside any repo as a safe place for sample data, helper scripts, and temporary notes that should never be committed. Putting a self-ignoring `.gitignore` file inside the directory makes the pattern portable even without extra repo changes.

    If people on your team keep creating ad hoc local files in repos, standardize on one disposable directory name and add it to user-level ignores. It gives developers a sanctioned scratch space without polluting project policy.

      Attribution:
    • judofyr #1
    • deathanatos #1
    • weinzierl #1
    • williamjackson #1
    • zahlman #1
    • thewisenerd #1
  5. 05

    Local excludes are great for personal workflow files

    `.git/info/exclude` turned out to be especially useful for clone-specific Makefiles, helper scripts, and sample-data paths that only make sense on one machine or during one debugging session. That is a cleaner fit than committing those files or teaching every repo about them, because the rules live with the clone and disappear with it.

    Use `.git/info/exclude` for files that matter only in one checkout. It is the right tool for local automation you do not want following you across machines or showing up in code review.

      Attribution:
    • bryancoxwell #1 #2
    • junon #1
    • digikata #1

Against the grain

  1. 01

    Shared ignores can be the cheaper fix

    In contributor-heavy projects, adding obvious entries like `.DS_Store` to the repo can save more time than insisting every developer configure their machine perfectly. The point is not elegance. It is reducing accidental commits, rejected pull requests, and repeated cleanup work. One commenter also claimed newer macOS setups may already ship with a global `.DS_Store` ignore, which would shrink this problem, but maintainers still argued that repo-level guardrails are often the more reliable operational choice.

    For open source or large teams, optimize for fewer mistakes, not ideal configuration hygiene. If the same junk file keeps showing up in reviews, adding one repo rule may be cheaper than more education.

      Attribution:
    • wccrawford #1
    • nomel #1
    • eyelidlessness #1
    • mvdtnz #1
    • tom_ #1
  2. 02

    Per-user config breaks down in ephemeral environments

    Global ignores assume a stable personal machine. That falls apart in dev containers, rebuilt environments, and casual contributor setups where local config is not persistent or not present at all. In those cases, a repo `.gitignore` entry is often the only solution that survives the environment people actually use.

    If your team develops in containers, Codespaces, or frequently rebuilt environments, check whether user-level ignore rules persist before standardizing on them. Otherwise you will create policy that works only on long-lived laptops.

      Attribution:
    • Anon1096 #1
    • xboxnolifes #1 #2
    • 8cvor6j844qw_d6 #1

In plain english

.git/info/exclude ↩
A per-repository local ignore file inside a specific clone that Git uses like `.gitignore`, but which is not committed or shared.
.gitattributes ↩
A Git configuration file that assigns behaviors to tracked files, such as how diffs, merges, or line endings should be handled.
.gitignore ↩
A file in a Git repository that lists untracked files and patterns Git should ignore for everyone using that repository.
assume-unchanged ↩
A Git index flag that tells Git to stop checking a tracked file for local modifications until you unset the flag.
git check-ignore ↩
A Git command that tells you whether a file is ignored and which ignore rule caused it.
global ignore file ↩
A per-user Git ignore file configured in personal Git settings so certain files are ignored across all repositories for that user.
package-lock.json ↩
The npm lockfile for a JavaScript project that records the exact versions of all installed dependencies, including transitive ones.
skip-worktree ↩
A Git index flag that tells Git to avoid treating local changes to a tracked file as relevant in normal operations.
uv.lock ↩
A lockfile used by the Python tool uv to record exact resolved dependency versions.

Reference links

Git documentation and tooling

  • gitignore documentation
    The canonical Git documentation that the post largely summarizes and commenters pointed people to directly.
  • Project-level Git config
    An example of using Git config includes and excludes to apply settings across multiple repositories in one project directory.
  • Git man page generator
    A joke tool mentioned in a side conversation about Git’s complexity and confusing documentation style.

Background reference