4 ms·
You can actually achieve this by making a new branch at the merge-base, cherry picking the fix from the development branch, then landing this branch into the re
by frutiger 7y ago
You can actually achieve this by making a new branch at the merge-base, cherry picking the fix from the development branch, then landing this branch into the release and development branch.
Git will record the parent commit correctly on both branches but apply no changeset to the development branch, while applying it to the release branch.
I admit the above is a bit much for most people.
- pmeunier 7y ago> I admit the above is a bit much for most people. True, but it's not just the UI: this also requires discipline and constant synchronisation in a team. Pijul achieves the same without much discipline.
- mjw1007 7y agoIt'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.