`git commit -a` is harmful and should not be used

[meagar]

You should not use git commit -a or suggest that other people use it or write tools that use it. You should be using git add -p or git add -i to thoughtfully stage changes and actually have some awareness of what you're about to commit.

There are thousands of questions about how to remove accidentally committed files from Git, for example https://stackoverflow.com/questions/20808373/how-to-remove-some-files-accidentally-added-in-the-first-commit

git commit -a adds everything that you didn't think to put in .gitignore, including output files, log files, .env files potentially containing secrets, temp files created by your editor, etc etc.

You not only use git commit -a, but you follow it up with a git push meaning that your mistakes are instantly published and become harder to undo.

You should never recommend this approach to anybody, but especially not to new Git users who are going to have a really hard time undoing the harm this causes.

[Leon-Africa]

Hi @meagar,

Thanks for your comment - I definitely hear your concerns.

The idea behind this command is to do exactly what it says: commit and push all changes and the assumption is that that is exactly what the user wants to do. As the assumption with the native -a option.

The entire project is an layer on top of already existing git commands, so this option would have to be included because its part of the git ecosystem.

I think an addition to overcome this in some way would be to check that a .gitignore is present in the directory and search that common .gitignore elements that may be present in the directory are actually stipulated in .gitignore. Probably using this: https://github.com/github/gitignore and perhaps autogenerate if not exists. Also run a git status with a confirm option for file list.

These are the current ideas I see to make it a little bit "safer".