> I just see that as friction. Now a developer who is working on a new feature is reluctant to take opportunities to refactor incase their commit message doesn't match the "standard". Empower the developer and reduce friction to a minimum is my modus operandi.
Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.
>Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.
Which again may result in that refactoring never getting done. Many times I've found myself saying to myself "I must refactor this class.. But I'll just finish implementing this feature first so that I can get a clean commit with only the refactoring afterwards". Suddenly it's 5 o'clock and tomorrow I've forgotten about the refactoring need.
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.
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.
I struggle to see how this adds so much more effort?
You already know you want to refactor it so its not about forgetting to do it, and once the feature is done you'll probably have a better idea of how to refactor everything better and faster. It should actually save time in code productivity vs the extra minutes to do another commit.
Honestly those commits should probably be split anyway. A commit should represent the smallest 'change' which is singificant.