diff --git a/pages/blog/stacking.md b/pages/blog/stacking.md
index fdb2d29..248e711 100644
--- a/pages/blog/stacking.md
+++ b/pages/blog/stacking.md
@@ -3,7 +3,7 @@ atroot: true
template:
slug: stacking
title: jujutsu-style code review
-subtitle: we now support jujutsu style "interdiff" code-review!
+subtitle: tangled now supports jujutsu change-ids!
date: 2025-06-02
image: /static/img/hidden-ref.png
authors:
@@ -49,7 +49,7 @@ Consider a hypothetical PR that adds 3 commits:
[a] some small refactor
```
-And when only *newly added commits* are easy to review, this
+And when only newly added commits are easy to review, this
is what ends up happening:
```
@@ -86,15 +86,16 @@ there is an implicit relation between each change:
This has the downside of clobbering the output of `git
blame` (if there is a bug in the new feature, you will first
land on `e`, and upon digging further, you will land on
-`b`).
+`b`). This becomes incredibly tricky to navigate if reviews
+go on through multiple cycles.
## the interdiff model
With jujutsu however, you have the tools at hand to
fearlessly edit, split, squash and rework old commits (you
-could do this with git if you are familiar with fixup
-commits or interactive rebasing).
+can absolutely achieve this with git and interactive
+rebasing, but it is certainly not trivial).
Let's try that again:
@@ -206,7 +207,7 @@ This submits each change as an individual pull request:
-