diff --git a/input.css b/input.css
index 92f4669..b291461 100644
--- a/input.css
+++ b/input.css
@@ -51,9 +51,14 @@
scrollbar-gutter: stable;
}
@supports (font-variation-settings: normal) {
- html {
- font-feature-settings: 'ss01' 1, 'kern' 1, 'liga' 1, 'cv05' 1, 'tnum' 1;
- }
+ html {
+ font-feature-settings:
+ "ss01" 1,
+ "kern" 1,
+ "liga" 1,
+ "cv05" 1,
+ "tnum" 1;
+ }
}
a {
diff --git a/pages/blog/stacking.md b/pages/blog/stacking.md
index 248e711..52967f8 100644
--- a/pages/blog/stacking.md
+++ b/pages/blog/stacking.md
@@ -2,7 +2,7 @@
atroot: true
template:
slug: stacking
-title: jujutsu-style code review
+title: jujutsu on tangled
subtitle: tangled now supports jujutsu change-ids!
date: 2025-06-02
image: /static/img/hidden-ref.png
@@ -20,13 +20,13 @@ commits, and also see the evolution of a commit over time,
as reviews are addressed. We set out to natively support
this model of code-review on Tangled.
-If you're new to Tangled, [read our intro](/intro) for more
-about the project.
+Tangled is a new social-enabled Git collaboration platform,
+[read our intro](/intro) for more about the project.
For starters, I would like to contrast the two schools of
code-review, the "diff-soup" model and the interdiff model.
-## the diff soup model
+## the diff-soup model
When you create a PR on traditional code forges (GitHub
specifically), the UX implicitly encourages you to address
@@ -124,22 +124,16 @@ Rebased 2 descendant commits onto updated working copy
[a] some small refactor
```
-This is the most important part:
-
-```
-Rebased 2 descendant commits onto updated working copy
-```
-
Jujutsu automatically rebases the descendants without having
to lift a finger. Brilliant! You can repeat the same
exercise for all review comments, and effectively, your
PR will have evolved like so:
```
- a -> b -> c
+ a -> b -> c initial attempt
| | |
v v v
- a' -> b' -> c'
+ a' -> b' -> c' after first cycle of reviews
```
## the catch
@@ -155,8 +149,8 @@ to `b'` etc.
Jujutsu however, works around this by assigning stable
"change id"s to each change (which internally point to a git
-commit, if you use the git backing). If you edit an old
-commit, its SHA changes, but its change-id remains the same.
+commit, if you use the git backing). If you edit a commit,
+its SHA changes, but its change-id remains the same.
And this is the essence of our new stacked PRs feature!
@@ -210,8 +204,8 @@ This submits each change as an individual pull request:
The "stack" is similar to Gerrit's relation chain
-After a while, I receive a couple of review comments, but
-not on my entire submission, but rather, on each *individual
+After a while, I receive a couple of review comments, not on
+my entire submission, but rather, on each *individual
change*. Additionally, the reviewer is happy with my first
change, and has gone ahead and merged that:
@@ -275,7 +269,7 @@ $ jj edit so
# hack, hack, hack
```
-We are done addressing reviews, let us push our code:
+We are done addressing reviews:
```
$ jj git push
Changes to push to origin:
@@ -283,8 +277,8 @@ Changes to push to origin:
```
Upon resubmitting the PR for review, Tangled is able to
-accurately map every change in the resubmitted branch to its
-original PR, using jujutsu change-ids:
+accurately trace the commit across rewrites, using jujutsu
+change-ids, and map it to the corresponding PR: