Is this not the common way most people commit?
I usually make a bunch of changes at once. Following a break I review the changes and break them up into logical commits.
I aim do break up changes so that the commit log can be read like a book and. I can guarantee that not a single commit contains hidden surprises or unrelated changes.
I don't know how most devs get by with just the CLI. A lightweight gui makes commits and reviewing the history tree so much easier.
That said, philosophically I'd personally prefer to just commit the small features individually as a set of small commits, therefore you get a better git blame/praise experience with the end result, but I realize there is a wide spectrum of preferences on commit size and style.
However, many of my peers and co-workers have a hard time following the small-commit workflow, so this project is really for them.
Being able to mark small (but significant) changes in your code as you code definitely helps reduce some ambiguity in commit messages.
Git blame displays the last commits that updated your files lines.
This gives you the ability to write your commit description while you code.
This builds the initial commit message when you want to commit the pending changes in the index.
i guess its still very useful if you are working somewhere where that bad practice is enforced.
maybe encourage is the wrong word, but it seems like a useless tool if you are doing things in (what i perceive to be) the right way.
