Description
The --rebase-merges mode allows users to rebase entire branch thickets, rather than only a linear commit history.
This feature can also be used to structure otherwise too-long patch series. Essentially the history looks like this:
o - A - B - C -D -E -F - G - H - I ...
\ \ \
------------ first-batch - second-batch - ...
This makes sure that the whole feature can be developed from beginning to end, still keeping the "first-batch" in a shape that can be contributed individually to the Git mailing list. And then fixes (e.g. as a reaction to code review comments) can be integrated via git commit --fixup and then git rebase -ir.
However, the local branches first-batch and second-batch are not updated that way; They still have to be updated manually, which is tedious and error-prone.
How about an option to --rebase-merges that teaches label commands to see whether there is a local branch of the same name whose tip commit corresponds to the pre-rebase state of this label, and if such a branch was found, it is updated automatically (even updating a worktree if there is one, much like the receive.denyCurrentBranch=updateInstead feature does on push).