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.

If it's only needed for one particular checkout, .git/info/exclude is the other obvious option.

(disclaimer - this is my own tool)

[0] https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...

Especially the humility it requires - remember being mad when my younger brother joined my Factorio game and changed smelters setup. To an actually better one - one thing when people correct your technical solutions, double so bad when they are actually right.

You clearly haven't seen the people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.

You see the issue right?

Adding extra, sensitive, files would not cause test failures, and even if they do (via secret scanners, etc), it is too late at that point because they will have already been shared upstream.

I am not sure the juice is worth the squeeze here, but it has some logic to it.

I’ve worked with and managed plenty of people like that and those are the people I least want doing something like this. Seeing the flotsam and jetsam of .DS_Store etc. are an early warning sign they aren’t paying any attention to what they push and the sooner that gets caught and addressed the better.

Pay attention to what you are committing. Generally this means looking at what you have staged before writing your commit log message.

Pay attention to what is in your pull request. Generally this means looking at your commits / draft pull request before you ask for code review.

If anybody other than you sees crap in your pull request that should obviously have been ignored, it means you have failed to pay attention to what you are doing three separate times.

  > people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.

Doing that on projects where I collaborate I would equate to pissing in public.

That is also why pull requests are such a great idea in general, because GIT allows one to piss in his own garden as much as they want.

Even if I could piss in my own branch I never do so when working on a project with other people.

I don't piss around my home obviously in case someone didn't get the metaphor.

    ```.gitignore
    # Ignores
    ## Unix hidden files
    .*
    ## Temporary files and backups
    *~
    *.swp
    *.bak  
    
    # Exceptions
    !.ignore
    !.gitignore
    ```

Now, I could extend my user-global ignore, but there's no project where I want the state of the repo to be wrong, but my local state saving me unknowingly, as I know it'll bite others.

I'd add .nvmrc and .npmrc if you work with NodeJS.

I think rules for your personal tools, like editor-specific ignores belong to your user-level config, but anything around the project's tools and artifacts belongs in the project's gitignore.

Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.

It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.

Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs.

Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging.

People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer.

I recommend looking here: https://git-scm.com/tools/guis

(it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience)

Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!

Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?

But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.

Not pushing a file has a much easier fix than pushing an API key. The damage is also very different.

Sure, both have failure modes but the effect of the failure is different and acting like they're the same isn't helpful to finding solutions

I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.

Like git rebase -i as well

Keys that are deleted are not gone from the git history. They’re still in the repo.

Same with giant blobs and binaries.

Or even better, have a proper global gitignore file on your computer…

Maybe that's more ergonomic than forcing all users to learn about ~/.gitignore or manually adding .DS_Store *.sav~ et cetera into your Go project's repo's .gitignore.

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.

Finally can have Emacs files ignored automatically in all projects. <3

Please do.

What is weird about it?

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

A "security engineer minded approach" would be: own what is executed on the box;

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’m far more interested in confirming my mental model of what I am about to commit if I git commit right now than my mental model of what will be added if I git add right now.

If I didn’t already have that muscle memory I might try to switch to git add -v . which would tell me what files it added. I’d argue that a sane git would just output git status after a git add operation.

But also a sane git would have a more logical command than git rm —cached to unstage a file. Like git unstage perhaps.

This is actually a general problem with git and most cli tools, where it would be possible and useful to undo an action, but the tool developer cannot be bothered to implement such time-saving feature.

    git reset

to unstage files you ran git add accidentally on

But to be clear: I’m the kind of person who runs git add .; that means I’m not maintaining a secret hidden third set of changes in the cache. I’m making changes in my working directory, and when those changes are in the shape I want them to be, I am staging all of those changes so I can commit all of those changes. If git add . overwrites a previous state of cached files, that’s fine - if I didn’t commit them I don’t want them.

Committing a codebase state that only exists in the cache and in your mind, on which you haven’t therefore run any build or test or linting tools because that precise set of changes has never existed in isolation in your codebase strikes me as requiring far too much mental powerlifting.

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

https://kapeli.com/cheat_sheets/Oh-My-Zsh_Git.docset/Content...

Increasingly with agents I'm likely working on multiple features in parallel (I haven't adopted git worktrees but I probably should). Even then I try to lay out code so concurrent changes touch disjoint parts of the codebase, so I can do "git add Widgets/FooWidget/" and the ten files modified under there will be the right things to commit.

Maybe 30% of the time I find I have done work that belongs in multiple commits and I need to break it up. Even then I often end up doing "git add -p ." to interactively pick the parts I want to add.

[0] https://github.com/jesseduffield/lazygit

You can also select specific hunks or lines within a hunk to stage/unstage.

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?

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

CLAUDE.local.md is the one that should be in .gitignore.

(disclaimer - this is my own tool)

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

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

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.

(disclaimer - this is my own tool)

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

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

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.

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

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

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

(disclaimer - this is my own tool)

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

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

You need to merge the relevant ignore files to create one specific for you, so if you use VSCode on macOS VisualStudioCode.gitignore (e.g., .vscode) + macOS.gitignore (e.g., .DS_Store). There are files for other OSs and editors as well. Technically their README says that the Global folder is intended for user-specific ignore files. But you can still use them for the repo .gitignore.

There is also this API which you can curl: https://gitignore.io/api/macos,vscode

Some of the templates seem to be identical, but I think they are not in sync.

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.

The -p presumably stands for pInteractive with a silent p :)

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?

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

For Golang users, I dunno...

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

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.

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

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.

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

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.

~/.project-name/local.env

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

Works well so far

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 author likely meant .dockerignore everything, that is the way to go.

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

  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"
  }

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.