This seems like a nice idea, but - this could be just me - my commits are rarely a couple of changed lines. I usually commit on an "entity" basis where I make one class/module/function along with the tests for it and commit.
Maybe a tool like meld[1] (which already supports diff-ing between your working copy and HEAD) gaining this capability to step through commits would be quite useful.
That's how people usually work with traditional centralised VCS, but with a DVCS like git the "commit early, commit often" strategy is viable. You should try it - create a branch for your new class, commit to it as you go, then when it's done, commit it back as a merge on mainline.
I completely don't see the "commit early, commit often" idiom working. It may be a viable method of deployment, but I honestly fail to see how it would improve commits.
For me, the "atomic commits" strategy is still the way to go. Whether it's early, or often, doesn't matter to me. In that regard, nothing has changed since I've switched to DVCS. I might even go so far as to say, if you've changed commit strategies since switching to DVCS, you weren't using your centralised VCS correctly.
The "branch early, branch often" strategy is an entirely different matter though.
Thanks. that was one of my hopes actually - that someone would see git-playback and think 'wouldn't it be cool if <insert-tool-name-here> could do something like this?'
Maybe a tool like meld[1] (which already supports diff-ing between your working copy and HEAD) gaining this capability to step through commits would be quite useful.
Still good idea, though!
[1]: http://meldmerge.org/