I think this is fun, but that the correct solution is to stage files one at a time, after confirming they contain what you expect. This allows you to be incredibly hectic in your development, because you can trust yourself to reel it all back in at commit time. It also means you won't accidentally commit secrets (eg keys) or random files that accidentally wound up in the directory. It also means your commits will probably be much more coherent, b/c you'll be much more aware of what's in them, and you can break them into sensible chunks (eg git add -p)
Nice, I didn't know about commit -v I still have to do it one file at a time, though. If I don't think about what's in the file before looking at the diff, I wind up glossing over it and not being in tune with my commits.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this is fun, but that the correct solution is to stage files one at a time, after confirming they contain what you expect. This allows you to be incredibly hectic in your development, because you can trust yourself to reel it all back in at commit time. It also means you won't accidentally commit secrets (eg keys) or random files that accidentally wound up in the directory. It also means your commits will probably be much more coherent, b/c you'll be much more aware of what's in them, and you can break them into sensible chunks (eg
git add -p
)Hmm, like to commit often, and use
git commit -av
. The verbose option gives me a diff, which I use to make my pre-flight checks.Nice, I didn't know about
commit -v
I still have to do it one file at a time, though. If I don't think about what's in the file before looking at the diff, I wind up glossing over it and not being in tune with my commits.