[iamjs]

I have long wanted a tool to help split large diffs into smaller semantic changes. When you're working on a feature, for example, and end up refactoring along the way, you may wish to have your refactor reviewed and merged without any new functionality.

[Cthulhu_]

That's when you should stop your work, make a new branch from main, do the refactoring and offer it separately; it's about (self) discipline in the end. You can probably also do something creative with cherry-pick and the like.

[iamjs]

Sometimes I do this, but sometimes it's just more work than it's worth. I have started to do this a bit more with language models to help reduce the toil, but I yearn for a more rigorous method.

[hebetude]

It’s painful but this is the way. Especially if your team is slow at merging.

[rav]

Given a commit that both refactors (A) and adds a feature (B), you can go into the codebase and remove the new feature by hand (B^-1), commit the feature removal, and immediately revert the feature removal. This leads to three commits: (A B), B^-1, and B. Squash the first two commits to obtain a commit that only refactors, and another commit that only adds the new feature. I've written more about this technique ("the Hammer") here: https://github.com/Mortal/gittalk