rebase -ir: optionally auto-update local branches when executing label commands

[dscho]

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).

[phil-blain]

@dscho I think this workflow is now easier with --update-refs, no ? (not sure if it completely solves this here issue though, as I've not tried it along with --rebase-merges)

For lurkers:

• https://github.blog/2022-10-03-highlights-from-git-2-38/#rebase-dependent-branches-with-update-refs
• https://github.com/git/git/blob/262c45b6a17d971cd440c6cd2fdeff1e0d081e47/Documentation/RelNotes/2.38.0.txt#L36-L37

[dscho]

Yep, this is addressed. Another useful reference: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---update-refs