Live data from Hacker News

.gitignore Everything by Default

packagemain.tech

21–30 of 182 posts

Re: .gitignore Everything by Default

#21
post #14
post #4

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.

I use "git add ." (or rather -A), but I will always do a "git status" first to make sure I'm not doing something silly. Of course you still have to be careful about subdirectories, which is why I usually also do a "git status" again before committing.

another `git status` then `git add .` folk here, it's a quick sanity check and then quicker and frankly it's just the habit I got into when I first started using git.

I've never managed to get on with any UI for basic git tasks, they always end up been slower.

Re: .gitignore Everything by Default

#22
post #20
post #5

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

What does that do, add already tracked files only?

It interactively shows you each change that would be added and lets you decide whether it should be staged or not. Down to the hunk level, so you can partially stage a file if you so choose.

Re: .gitignore Everything by Default

#23
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.

Re: .gitignore Everything by Default

#24
post #16

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

Yeah, I don't see myself using this for Git (where it's very easy to see what you're adding, but not obvious and high-cost if you're missing something), but it's my standard approach for Docker images (where it's easy to tell that something is missing, and low-cost to fix it).

Re: .gitignore Everything by Default

#25
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?

Re: .gitignore Everything by Default

#27

> 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?

IME people are usually shoving their personal preferences in CLAUDE.md, sometimes automatically as the agent updates the file with that developer's pet peeves.

- Right now at $WORK, CLAUDE.md has a line saying to put one-off scripts in some gitignored place. That's fine if they're not worth checking in (IMO, you should build the tooling which would have made the script easy and check that in, but whatever), but that AI rule doesn't really keep them from being checked in -- developers manually review every line of code and decide what to check in -- that's just somebody deciding they'd rather not have to think so hard when running git add. Which is fine, but it directly conflicts with my preference for all AI-generated files to be plainly visible as a diff or with git status or something. They have a different diffing strategy, which is also fine, but that's just a dev's personal preference encoded in a whole-team doc.

- Or, I have a prompt I use to encourage higher quality code before I have to manually inspect it. It basically says "delete $200 and 1hr." For somewhat obvious reasons, I don't run it on every piece of code the AI shits out. I make it available in the project for people who want to use it, but I don't even want it in my CLAUDE.md, much less the team's.

- Similarly with whether to use git for checkpointing. I prefer to check the AIs output at each step. A colleague prefers to have it save its progress using git in 30+ commits on a side branch and then check them all at once. One of those workflows was in CLAUDE.md and absolutely is not anymore -- it's quite appropriate for a single developer's AI settings, but not for the team as a whole.

Those settings files are a lot closer to .vscode directories or other dev-specific editor configuration. Project-specific information should be exposed differently.

Re: .gitignore Everything by Default

#28

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 lik…

I normally go with `.*/` -- I find that hidden files are much more likely than hidden directories to be useful.

Re: .gitignore Everything by Default

#30

- 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

Because it's insufficient?

https://github.com/github/gitignore/blob/main/Rust.gitignore for example still falls victim to basically all of the issues specifically called out.

Post reply on HN