> Short-lived branches are another poor simulation of patches: if Git were really working on patches, you would be able to create a branch "after the fact", mea

> Short-lived branches are another poor simulation of patches: if Git were really working on patches, you would be able to create a branch "after the fact", meaning that you would work (possibly on multiple features at the same time), and push different parts of your work separately, without having to worry about branches before you start. You made me remember something I've been annoyed with version control systems. Which I've found hard to explain. But your comment makes me think about what doesn't come across. The problem with version control systems is they are stand alone tools that don't capture and record refactoring. What you want is not a patch/diff. You want a record of the refactoring commands, and the result as separate things. And the ability to tag those. 1 Tag with meta data (commit message etc) 2 Command: Change this method name from this to that. 3 ChangeSet: List of 371 places where the change was made. Consider if you have a couple of projects that rely on a framework/library. You could apply the commands to each project. And automagically get change sets for each.