When you're debugging or reading code, you often want to know what a particular line of code was originally supposed to be doing. Maybe you want to know if it'

When you're debugging or reading code, you often want to know what a particular line of code was originally supposed to be doing. Maybe you want to know if it's OK to remove it, or you don't understand why it's written a certain way. If you can go back to the commit where the line was added and find some meaningful information about what that commit was supposed to be doing, that gives you a lot of information about what the code itself was for. This leads to a commit style where each commit has a well-defined purpose rather than just being a snapshot of the code at a point in time. You make frequent commits while writing the code, but once it's working, you go back and create distinct commits for each distinct change. While you're splitting your changes up, you sometimes realize you forgot something, made a mistake, or left some junk around you didn't mean to commit, which is a nice secondary benefit.