Stop committing .DS_Store: the per-user Git ignore that maintainers keep rejecting PRs over
A maintainer in the thread says he routinely gets PRs adding IDE and OS junk to a project's .gitignore, and routinely tells contributors there's a global ignore file that does it everywhere, once. Twenty-year veterans in the thread admit they'd never heard of it.
A short post listing Git's lesser-known ignore mechanisms, .git/info/exclude (per-repo, uncommitted) and ~/.config/git/ignore (per-user, everywhere), hit the HN front page. Some called it a rehash of the man page.
But the thread turned into a swap meet of tricks the article skipped: .gitattributes to hide noisy diffs like package-lock.json, and update-index --skip-worktree for files already tracked. A maintainer's takeaway: stop putting your editor's clutter in everyone's .gitignore.
Three places Git looks before it tracks a file
The post makes a simple point: .gitignore is the shared, committed list, but it isn't the only one. There's .git/info/exclude, which lives inside a repo's .git directory and is never committed, ideal for personal files only you care about in that one repo. And there's the per-user global ignore at \~/.config/git/ignore (configurable via core.excludesFile), the right home for things like macOS's .DS_Store so they vanish from every repository at once. It also flags git check-ignore -v <file> as the way to find out which rule is hiding a file. The discussion ran past 120 comments.
The rule a maintainer wishes everyone knew
The practical payoff showed up in a maintainer's recurring annoyance, and it's the reason the global file matters.
"I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere." — a project maintainer
The reach of that gap was its own subplot. "I am a professional software dev for 20 years… and only ever used .gitignore," admitted one commenter. Others pushed back that the article was thin: "a very low-effort regurgitation of" the official gitignore docs, one wrote.
The tricks the article left out
The thread's real value was the techniques beyond the three the post covered, for cases plain ignoring can't handle.
"Fun article, but it leaves out my favorite 'almost ignore' feature in Git:
.gitattributes. This file lets you specify that git should 'ignore' the diff from certain files. For instance…package-lock.jsonthat is pure noise from a Git standpoint." — a commenter on diff suppression
For files Git is already tracking, where .gitignore does nothing, two more surfaced. One pointed to git update-index --skip-worktree for local experimentation on committed files, with the caveat that it's invisible and easy to forget you set. Another shared --assume-unchanged aliases for the same problem.
A man-page rehash that taught a lot of senior devs something
The meta-lesson sits in the split between the two reactions: critics called it a regurgitation of git help gitignore, while twenty-year veterans confessed it was news. Both can be true. The article's three mechanisms are documented; the thread's extensions, .gitattributes for diff noise and skip-worktree for tracked files, are the part worth bookmarking. If you've been padding every repo's .gitignore with .idea/ and .DS_Store, the fix is one file in your home directory.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
He moved dotfiles from GNU Stow to Chezmoi. The thread climbed to Nix
The complaint that triggered the switch is tiny and specific: symlinks cut both ways, so every edit writes straight back into the repo and silently makes the tree dirty. The fix opened a 116-comment ladder where every rung tries to sell you the next tool up.