It's still not ideal. With git's DAG-based "patch model", I think what you'd really want to do is, after making the new branch and cherry-picking the fix, make

It's still not ideal. With git's DAG-based "patch model", I think what you'd really want to do is, after making the new branch and cherry-picking the fix, make that new commit a second parent of the original commit (so that it becomes a merge, but its tree doesn't change). I think that would leave the graph with the best representation of what's going on (ie, the same thing as if you'd made the patch from the merge-base in the first place). But git's hash-based system for identifying commits won't let you add new parents.