[otherusername2]

I can't imagine my workflow being all that special, but I never have to deal with this?

I just write new features, refactor if needed, fix unrelated bugs, etc. When I feel like it's commit-time, I cherry-pick changed chunks or lines to commit into single coherent commits. If I've introduced a new feature that required refactoring, I'll first pick all the chunks that belong to the refactoring and commit; then I'll commit the new feature and afterwards commit any bugfixes and other side endeavors that may have come up during the development of the new feature.

This is one of the reasons I don't like working with Subversion anymore. Committing, say, two changed lines in a file with many changes is nearly impossible. In 'git gui' it's a simple as selecting the lines, right-click, "Stage lines for commit" and pressing the commit button, and I'm back to working on whatever it was I was really working on.

[sbov]

I find this method to not work too well for me because oftentimes features will have changes to the refactored code.

So I'm stuck with undoing my feature code or leaving smells of my feature in the refactored code.

Maybe I'm doing something wrong though.

[hahainternet]

I tend to do this but with git add -p

[otherusername2]

I did this too in the past, but I've since found the convenience of 'git gui' too hard to ignore. The fact that it seamlessly runs on remote servers over X forwarding without having to install anything on the remote server really helps.