Updating dependent branches when rebasing, automagically
I'm regularly rewriting my history, often with the lens of improving my commit messages.
On the Renovate project, we use a Merge Queue with Squash Merge, which means that if I do want to have atomic commits, I need to split them across PRs, which adds a bit of noise to manage them.
Alternatively, I could bypass branch protection requirements to do a rebase merge, but that's the only way to do a rebase merge with a Merge Queue.
Now that GitHub has launched stacked PRs, it's now possible to get this behaviour as I wanted, but with the safety of the Merge Queue.
But the issue is what happens when I've amended the commit message on one of the PRs, and now need to trigger a cascading rebase?
As of ~5 minutes ago, I would have to do that all manually, like a chump.
It turns out - thanks to a pointer from Claude Opus 5 - Git has had a capability to improve this for years! In Git 2.38 (2022-10-03), git rebase --update-refs was added, which allows doing exactly this, but without any of the manual work.
For instance, if we run git rebase -i origin/HEAD --update-refs, we'll get a prompt in our $EDITOR like so:
pick 5c02d5df35 # fix(platform/bitbucket): remove support for Issues
update-ref refs/heads/fix/bitbucket-cloud-issues-removed
pick 8dd04828d3 # feat(http/bitbucket): surface deprecated and removed API functionality
update-ref refs/heads/feat/bitbucket-surface-api-deprecations
pick e7c9902237 # refactor(http): add a `handleResponse` hook
update-ref refs/heads/refactor/http-handle-response-hook
pick b989428159 # feat(http/bitbucket): warn when an endpoint announces a deprecation
# Rebase 7d7f286dc8..b989428159 onto 7d7f286dc8 (7 commands)
#
# Commands:
# ...
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
# to this position in the new commits. The <ref> is
# updated at the end of the rebase
# ...
This then handles the updating of all the commits on relevant branches - a massive time saver!
