Sweet, looks like this is pretty new (2022).

Running a git command on one branch and multiple branches being affected is really unusual for me! This really does look like it is designed for just this problem, though. Simple overview: https://blog.hot-coffee.dev/en/blog/git_update_refs/

It breaks if you amend the top commit instead of adding a new one.

Is there any good guide on how to solve the issue which OP solves?

I was reading this the other day when I came across this feature because I’m stacking PRs recently which I don’t usually do

https://andrewlock.net/working-with-stacked-branches-in-git-...

Another commenter posted this link which was a bit more succinct

https://blog.hot-coffee.dev/en/blog/git_update_refs/

There isn’t much to it though, you just go to the branch and run git rebase with the update refs flag.

You don’t really need docs as --update-refs does what the OP does automatically instead of manually like the OP does.

How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":

  $ git checkout feature-1
  $ git rebase --update-refs main
  Successfully rebased and updated refs/heads/feature-1.
  Updated the following refs with --update-refs:
   refs/heads/feature-2-base

But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).

Presumably I'm doing something wrong?

Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case

    $ git rebase --update-refs main feature-2

Thanks! Yup, that does the trick.

First, you don't need the extra "marker" commit. This flag obviates the entire workflow.

Second, you run it on the outermost branch: feature 2. It updates all refs in the chain.