This idea comes from a repo[1] where I am experimenting with code variants: on one side I have a branch where I add to the core mechanisms, and on the other(s) I have several branches where I experiment with different rendering options. There are indeed 2 different workflows here: - improving the variants themselves, where occasionally some fixup or new commit for the core branch gets introduced - adding feature to the core branch, then merging that into each variant, where fixups already appear quite regularly That produces a set closely-related branches with lots of merges, and applying the fixups is a bit tricky. The "core + 1 variant" case pretty much works out of the box, with --rebase-merges and --update-refs generating a perfect instructions sheet. But if I was to rebase just one variant while rewriting the core branch, obviously all other variants would still fork off the pre-rewrite core branch, and we'd loose all chances of automating the same work on the other variants. OTOH, if I get `git-rebase` to generate the instruction sheets for those other variants first, strip them (manually) from the common part, and insert them in the instruction sheet of my "core + 1 variant" case ... I do get the whole of my branches rebased together, and sharing the updated core. So the question is, would there be any obstacles to let git-rebase automate this completely? By chance it could even be a trivial change? I guess we'd only want this feature to be enabled under certain conditions, like --update-refs being specified so the many heads of the rebase would be reachable. [1] https://github.com/ydirson/test-yew-tutorial/tree/opr is the "core" branch, and branches opr-* are the variants
