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
#
This then handles the updating of all the commits on relevant branches - a massive time saver!