[awolf]

Rather than `git add -p`, I suggest creating a second clone of your repo, staging your foundational refactor changes in the second repo, creating and merging your commits there, and then rebasing your working branch.

This makes sure you can fully test your refractors and that their change sets stand alone.

[dllthomas]

If you know your way around git well enough that you're not going to be screwing up repository state in ways you can't fix, there's no reason to operate from separate clones - check out git worktrees :)

[bacon_waffle]

Thanks for that! I've occasionally thought a feature like this would be possible and helpful, but hadn't encountered it until your mention.

[dllthomas]

I felt the same way when I stumbled across it in a man page :)

[CGamesPlay]

I use long-running git rebase -i with a line like “x false” to pause the rebase, run tests or finish packaging the refactor, then git rebase --continue.