Basically a lot of devs including myself tend to write a lot of code, then wait until the code is ready then we decide how to commit. Part of this is just we ar

Basically a lot of devs including myself tend to write a lot of code, then wait until the code is ready then we decide how to commit. Part of this is just we are focused on solving the problem, the other half is we like the commit to contain working code and code that looks pretty to read. Who would want to review code that's messy? I don't mind reading code that does not work for the sake of giving feedback whether one is heading in the right approach/direction. I've known people who don't care about how good the code is, they just keep committing, stating that's okay, because they will make sure at some point, most likely the head will contain fully working and tested code. When they merge they don't squash commits, they just merge because they believe full history instead of the glorified end state. I only do this to my personal project which I really don't care if the project ever takes off or if I am starting out the project for the first few weeks. I just need to get my project working. I usually take a trade off. I use the --patch option often to split my changes into logical commits. I also try to make sure when I have a working code I commit and if I need to fix a small typo here and there I just squash and rebase. For slightly larger change I can add that changeset as a new commit. I recommend folks to get used to using gir add -p option. It isn't hard to use the 'e' (manual edit) function, since the 's' split option cannot split lines further for something like: +line1=2 +foo='this is food' This line still here You use 'e' mode to split.