.gitignore Everything by Default

matthewmc3

I'm not convinced about ignoring everything, but one of the best changes I ever made to my git workflow was ignoring all dotfiles by default by adding `.*` to ~/.config/git/ignore. My projects do now have to have a boiler plate of unignoring the common ones (!.gitignore, !.gitattributes, !.github, !.editorconfig, etc), but then I'm free at any point to throw .foo.lang files, or .tmp/.cache dirs, or Claude helpers like .code_analysis.md, or .todos.txt, or whatever in my project without managing the fallout of forgetting to manage the .gitignore. I'm surprised more people don't go this route.

caseyw

I don’t ignore by default, but only stage the items I explicitly want. I can’t tell you how many times I’ve been pairing with someone when they just say “git add .”, I’m always confused by that choice. I get it, but I’ve seen more problems arise from adding all than being consistently selective. To each their own.

Lindby

`git add -p` is your friend to avoid adding unintended files/changes.

flexagoon

> other junk (CLAUDE.md for example) that shouldn’t be in your repository How is CLAUDE.md/AGENTS.md "junk that shouldn't be in your repository"? If you're using agents for a project and have some project-specific rules for them, why would you want other people using agents in your repository to not have access to those rules and produce worse code?

outloudvi

If people want to apply this mechanism, it shall be not much of a hassle for writers of most (modern) programming languages, as they mostly have some `src/` directory (maybe also some `tests/`) that contains all source codes for a quick `git add`. For Golang users, I dunno...

rcfox

This seems like bad advice. I've very rarely committed extra files by accident, but I would 100% forget to unignore files I meant to commit. If you're doing an initial setup step to gitignore everything, why not just do an initial setup step to gitignore the usual files? Make a template that you copy into all of your repos.

vehemenz

It's a neat approach for the current problem of untracked dotfile accumulation. The real problem is that the entire reason to use git at this point is because of the conventions established around it. There are better VCSes and methods now, but they "break" the conventions of git (which honestly sucks, but it is what it is).

queezey

This approach is actually ideal for Docker ignore files to reduce bloat of your Docker images.

internet101010

Put gates in place to block all .freeadvertising folders except for the ones that the project relies on.

monster_truck

I'm so sick of these articles telling me what to do with meaningless subjective justifications

ryanbrunner

The problem with this approach (that their first example already demonstrates), is that you'll almost immediately start with a "this type of file is OK" solution, and whether something should go in git doesn't really have a super strong correlation with file type. It hobbles `git status` and essentially forces you to keep track of what you've changed yourself (since ignored files won't show up there), and it can instill a false sense of security that `git add .` is safe when it might not be.

MatthiasPortzel

You should have editor specific and platform specific files in your global gitignore. https://codeberg.org/ziglang/zig/src/branch/master/.gitignor... That fixes the problem of every project enumerating the settings files for every editor. Then, as others have said, you should commit only the files you intend to commit; and ignore the files that you don’t intend to commit. This shouldn’t be difficult if you’re reviewing what you’re committing anyways. Listing new files is easy with git status, at which point you can decide to ignore them. If everything is ignored, how do you know what files are new in order to know to un-ignore them?

vivzkestrel

- or you could stop scratching your head so hard and actually use the gitignore templates for every programming language officially recommended by github itself - https://github.com/github/gitignore - funny how I did not see a single comment talk about this

jedschmidt

i do the same for Content Security Policy: `default-src 'none'` by default, then add what i need when i need it.

msalihb

I liked .gitcare This deserves think on it

bob1029

I've done something like this to understand how a unity project would interact with git + LFS as a novice to the ecosystem. I'd incrementally add files until the project would load successfully after a fresh clone. Handling of subsequent concerns like lightmap data and external services became a lot easier having had the experience built up from zero.

datsci_est_2015

Just use git add -p and review your code as you place it into staged-for-commit. Your colleagues will thank you for proofreading the slop before pushing it and opening a PR. Only add files after you’ve read them one-by-one as well. git add . is lazy and shows a lack of diligence. …is what I would say if I had no filter. But it does make sense what I see in PRs sometimes - have you proofread any of this before pushing?

morkalork

People still aren't committing CLAUDE.md?

Brajeshwar

It is weird that quite a few developers comes up with advices where they seem to come from a world where they work alone, have not work with enough people, or with enough projects. In this case, a `.gitignore_global` takes care of the usual suspects that he mentioned `.DS_Store files, IDE config, compressed files, etc.`. Even if something goes wrong, it is usually caught during the initial scaffold before critical files goes in. If one is working with new, young, rookie developers, give them the typical lesson on the global gitignore, local, config, and to have dotfiles, etc. Give yours for inspiration or something to start with. Edit: I know that mine is not the best of the dotfiles on the internet but this has helped me switch multiple devices, multiple identities (work, projects, personal, etc) easily. I recently cleaned it up and added automation, test, etc with Claude Code. https://github.com/brajeshwar/dot

chrismorgan

Not particularly well-considered opinion I’ve mulled over for a few years: Git on macOS should ignore .DS_Store and ._* by default. Would this cause any problems?