Where you leave commits is very subjective, and best left to the programmer to decide where the logical breaks should be. I follow these rules:
1) Start a new commit with a message describing your planned change immediately before doing any real work. Use an arbitrary file with a date or version number or whatever.
2) Commit frequently, --amend is your friend.
3) Don't be afraid to amend your commit message when you have to change your mind about what you need to do, but...
4) Stick to simple incremental changes that focus on the direction in which your program is evolving.
5) A commit (or its final amendment) must be a complete change, compile and run without obvious errors for all targets, and pass all tests.
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.
Where you leave commits is very subjective, and best left to the programmer to decide where the logical breaks should be. I follow these rules:
1) Start a new commit with a message describing your planned change immediately before doing any real work. Use an arbitrary file with a date or version number or whatever.
2) Commit frequently, --amend is your friend.
3) Don't be afraid to amend your commit message when you have to change your mind about what you need to do, but...
4) Stick to simple incremental changes that focus on the direction in which your program is evolving.
5) A commit (or its final amendment) must be a complete change, compile and run without obvious errors for all targets, and pass all tests.