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.
I also don’t commit files by accident. Just don’t `git add *` as some people do, and check `git status` before committing, and then you’re good.
I have a small user-global gitignore that most of the job for me,
```.gitignore
# Ignores
## Unix hidden files
.*
## Temporary files and backups
*~
*.swp
*.bak
# Exceptions
!.ignore
!.gitignore
```
But I tend to copy it over and extend it as I go, and there's well-known reference gitignore files to skim for if you have anxiety around any particular language/editor/tool.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.
> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
Most of the colleagues I've worked with only use "git add ." without checking first.
Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.
I dunno, I've never done what TFA suggests, but it makes sense to me. The idea isn't that your new foo.go file would be ignored by default; it's that your Go project's repo's .gitignore file would start with * and then !*.go , so that your new foo.go file would show up as untracked-and-unignored but your new foo.go.sav~ and .DS_Store and .foobarrc files would not.
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.
It is easy to do a rebase, adding more files to an already pushed commit. It is impossible to be sure, that no one has read already leaked secrets. Err on the side of caution.
> why not just do an initial setup step to gitignore the usual files?
Or even better, have a proper global gitignore file on your computer…
You can also use something like alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it to run as a pre-commit hook or in CI.
(disclaimer - this is my own tool)
[0] https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
In my 12 years of software engineering I've seen 10s of times people commit junk.
>This seems like bad advice. I've very rarely committed extra files by accident, [...]
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.
Recovery from forgetting to add something is _much_ easier than recovery from adding some weird configuration file with plaintext private keys in it.
orr, ~/.gitignore
For many years I've have a git-ignored ".not-committed" folder in all of my repos for throwing extra anything into. It's been a huge life saver!