.gitignore Everything by Default

Original Article ↗ Hacker News Discussion ↗

Advocates of “.gitignore everything by default” argue it reduces the risk of accidentally committing secrets, OS cruft, or IDE artifacts, especially when people habitually run `git add .`. Critics counter that this approach hides new files from `git status`, increases the chance of missing important source files, and is brittle in collaborative settings. Many instead recommend global and project-level .gitignore templates, more disciplined staging (`git add -p`, avoiding `git add .`), or tooling and CI checks to enforce what should and shouldn’t be committed.

Overall reaction to “.gitignore everything by default”

  • Many consider it bad or overkill: risks forgetting to un-ignore important files, breaking builds/CI, and hiding missing files from git status.
  • Supporters see it as a defensive, “deny-by-default” / security-minded strategy to prevent accidental commits of secrets, junk, or tool-specific clutter.
  • Several note it works better for certain contexts (e.g., Docker build contexts, Unity experiments, tightly structured repos) than for general development.

Selective staging vs blanket git add .

  • Strong theme: avoid blind git add . / git add -A.
    • Advocated alternatives: git add -u, git add -p, interactive staging, and reviewing git status before/after adding.
  • Some structure work so that git add . is safe (clean tree, single coherent change).
  • Disagreement on reversibility: some think “add everything” is easy to undo; others point out many users don’t know or use git reset / git restore --staged.

Global and local ignore strategies

  • Widely recommended: a user-global ignore (~/.config/git/ignore or similar) for OS/editor/tool files (.DS_Store, IDE configs, Emacs/Vim litter).
  • Others argue repo-level .gitignore should still defensively ignore common OS/editor artifacts, since not everyone maintains a global ignore.
  • Popular patterns:
    • Ignore all dotfiles globally (.*) but explicitly un-ignore key ones (!.gitignore, !.editorconfig, etc.).
    • Dedicated scratch/playground directories or per-directory .gitignore with * for throwaway files.
    • Use .git/info/exclude for personal, repo-local ignores that aren’t shared.

AI / agent config files (e.g., CLAUDE.md)

  • Disagreement on whether these belong in the repo:
    • Some see project-level AI instructions as useful shared documentation.
    • Others see them as personal preference dumps, closer to editor configs, and prefer a .local-style, gitignored variant.

Tooling, CI, and alternative safeguards

  • Several recommend GUIs/TUIs (Magit, lazygit, tig, IDE integrations) for visual diffs and hunk-level staging.
  • Some use linters/hooks (e.g., alint) or CI rules to block disallowed paths.
  • CI failing on missing files is seen as less damaging than leaked secrets, but others worry about lost work and “works on my machine” issues.