.gitignore Everything by Default

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.

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

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?

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 block every port for VPS, then open one by one. Same approach here with files.

The only downside I see here is, knowing which one to allow. For ports, it's easy, but files can have many different extensions.

Apps/CLIs, etc create files with extensions you never encountered before, which can cause issues.

Other than that, I like the apporach

You use Cursor which creates .cursor? Cool! Put it in .git/info/exclude. No need to pollute the project .gitignore with that. .gitignore is for artifacts that arise from the natural building and testing of the software, as well as any scripts in the repo.

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.

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.

- https://github.com/github/gitignore

- funny how I did not see a single comment talk about this

(disclaimer - this is my own tool)

[0] https://github.com/asamarts/alint

[1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...

Also, the .gitignore file can document what files you are supposed to have in your project and where they come from

[1]: I'm currently a happy Fork user after having tried Sublime Merge, Git Kraken and lazygit.

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.

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?

I'd say the correct approach is to include all your top level files (i.e. CMakeLists.txt, .gitignore, etc.) but also your top-level *directories*, i.e. `/renderer`, `/UI`, `/tools`, whatever.

Then, crucially, your build system must also prohibit in-source builds and require a dedicated build directory.

This way, it's presumed that everything in your source tree is pristine and correct, and can host a variety of file types depending on your needs (realistically, source trees can contain lots of things; data, json, images, text, etc.) while you also shouldn't have to worry about polluting it accidentally.

This one file was more sophisticated than any other file in the project.

It contained "good practices", editors/IDE files of applications dead for more than 10y, personal. /tmp directories in various names, files versioning using suffixes and comments for sections v of rules starting about in half of the file.

This project learned my to keep your own shit in local global gitignore not in project.

  strict_ignore() {
    [[ -n "$1" ]] || exit 1
    local repo="${1%/}/"
    local ignore
    ignore=$(find "$repo" -path "$repo".git -prune -o -print \
               | sed "s|$repo||g; /^$/d" \
               | awk '{print "!"$0}' \
               | sort)
    printf "*\n%s\n" "$ignore"
  }

The author likely meant .dockerignore everything, that is the way to go.

I've worked on projects with years-old local repos full of untracked junk, yet never needed .gitignore and never added and published anything by accident.

The habit of putting everything in /wrk folder will grow on you. Sometimes wrk folder is bigger than src

There, problem solved. This covers all cases I think.

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).

~/.project-name/local.env

And then referring to that location in the repo, say from a docker compose file.

Works well so far

For Golang users, I dunno...

Just look at git status before you commit :eyeroll:.

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