Comment by rcfox
21 hours ago
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.
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!
You can just add it in a user-level gitignore instead of ignoring it in every repo. See: ~/.config/git/ignore
I only realized very recently that being able to specify .gitignore files in any part of a repo can be combined with wildcards to just put `.gitignore` with `*` in a arbitrary directories to make them get ignored without needing to modify any wider configuration.
1 reply →
This has the disadvantage though, that this user level gitignore file will not be in the repo, which means that other less careful contributors have to fix ignoribg for themselves.
And then you have a known path to script up all your repos' stuff for backup
yes, but user level is not a repo level
2 replies →
i usually do "*ignorethis*", so a file with .ignorethis extension does not strictly have to be under a specific directory, this might save context somewhere. similar approach but yeah, a huge life saver!
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,
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.
> Now, I could extend my user-global ignore
I'd add .nvmrc and .npmrc if you work with NodeJS.
but if I add that to my user-global config instead of the projects I'm working with, I'd be making the deliberate choice of fixing things only for me and not anyone else for pretty much the exact same cost.
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.
> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
I do not think it is the right choice for any repository or developer. It just seems like terrible advice.
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.
The problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.
That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens.
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.
In my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
4 replies →
It's at least easy to fix.
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
> Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.
Keys that are deleted are not gone from the git history. They’re still in the repo.
Same with giant blobs and binaries.
That's the horror..
Genuinely curious - do you all not have a code review process, or do the reviewers just not care?
Pull requests in github are against branches, so keys and binaries are in the repo even if removed during review.
Secrets shouldn't be plain text in project directory >:[
> Most of the colleagues I've worked with only use "git add ." without checking first.
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.
Git becomes a lot easier to understand once you learn its "hidden" interactive flags
Like git rebase -i as well
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…
The repo should define rules for the repo, no? You have to hope other contributors have a similar local gitignore?
For files like `.DS_Store`, technically yes. Usually the people do not have a proper global gitignore, so we put these files in the gitignore of the repo, but it’s not repo-related, it’s OS-related… Same goes for editor files. The editor is something user-related, not project related (except e.g. for iOS development where the IDE is kind of more or less imposed).
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.
I'm not convinced people acting on muscle memory would remember to unignore the files either. They're going to lose work or have giant "oops, I forgot to commit these files" commits.
I do that for my personal projects.
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.
Now walk through exactly what would happen when those lazy people follow this approach…
You see the issue right?
I think the idea is that missing files will immediately cause issues (tests will fail, etc), so CI should catch this immediately.
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.
1 reply →
> 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.
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.
So the better alternative is for them to leave out files that should be committed?
People? Even LLMs do that
That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.
LLMs learned from people xD
I do this. What's wrong with this approach and how should it be done correctly?
Pay attention to what you are staging. Generally this means `git add -p` or similar.
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.
2 replies →
Recovery from forgetting to add something is _much_ easier than recovery from adding some weird configuration file with plaintext private keys in it.
It depends. I've lost hours of work after wiping and recreating a repo that had accidentally gitignored a file I was working on, and I didn't notice until too late.
I usually have *secret in .gitignore and append .secret to any files with secrets.
That's cute, too bad it's a config file mandated by your boss and it has to be called "terribletool.yaml."
1 reply →
orr, ~/.gitignore