181–185 of 185 posts
Earlier quoted context omitted.
Ban `git add .` for sure, but what’s so bad about `git commit -a`? It only adds/removes what was already under version control.
Makes it easy to commit things you didn't expect without having reviewed them
Earlier quoted context omitted.
git add . is nondestructive and reversible. I tend to do git add . and then run git status. 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 wou…
No, ”git add .” is not easily reverted, there’s no git sub command for de-adding files from the staging area. You have to copy the whole folder (hope you have enough disk space), checking out an older commit (hard), and copy specific files from the copied folder. Pita. 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…
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.
- 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
I don't like them, because they contain all sort of crap, that never even enters my projects, but they don't include things they should include, like the silly ".vscode" folder so many people commit without thinking. Also usually using these templates one avoids thinking and knowing what is ignored, until one accidentally commits something special to the project and boom, creating a huge hassle.
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.
- 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
These do not include os generated files like his first example, .DS_Store. I do use the templates, but I have a gist that I add to every project of os generated files that may work themselves in.
Very security engineer minded approach. 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;