tangled.org
oppi.li
+8
-3
input.css
+8
-3
input.css
···
51
51
scrollbar-gutter: stable;
52
52
}
53
53
@supports (font-variation-settings: normal) {
54
-
html {
55
-
font-feature-settings: 'ss01' 1, 'kern' 1, 'liga' 1, 'cv05' 1, 'tnum' 1;
56
-
}
54
+
html {
55
+
font-feature-settings:
56
+
"ss01" 1,
57
+
"kern" 1,
58
+
"liga" 1,
59
+
"cv05" 1,
60
+
"tnum" 1;
61
+
}
57
62
}
58
63
59
64
a {
+13
-19
pages/blog/stacking.md
+13
-19
pages/blog/stacking.md
···
2
2
atroot: true
3
3
template:
4
4
slug: stacking
5
-
title: jujutsu-style code review
5
+
title: jujutsu on tangled
6
6
subtitle: tangled now supports jujutsu change-ids!
7
7
date: 2025-06-02
8
8
image: /static/img/hidden-ref.png
···
20
20
as reviews are addressed. We set out to natively support
21
21
this model of code-review on Tangled.
22
22
23
-
If you're new to Tangled, [read our intro](/intro) for more
24
-
about the project.
23
+
Tangled is a new social-enabled Git collaboration platform,
24
+
[read our intro](/intro) for more about the project.
25
25
26
26
For starters, I would like to contrast the two schools of
27
27
code-review, the "diff-soup" model and the interdiff model.
28
28
29
-
## the diff soup model
29
+
## the diff-soup model
30
30
31
31
When you create a PR on traditional code forges (GitHub
32
32
specifically), the UX implicitly encourages you to address
···
124
124
[a] some small refactor
125
125
```
126
126
127
-
This is the most important part:
128
-
129
-
```
130
-
Rebased 2 descendant commits onto updated working copy
131
-
```
132
-
133
127
Jujutsu automatically rebases the descendants without having
134
128
to lift a finger. Brilliant! You can repeat the same
135
129
exercise for all review comments, and effectively, your
136
130
PR will have evolved like so:
137
131
138
132
```
139
-
a -> b -> c
133
+
a -> b -> c initial attempt
140
134
| | |
141
135
v v v
142
-
a' -> b' -> c'
136
+
a' -> b' -> c' after first cycle of reviews
143
137
```
144
138
145
139
## the catch
···
155
149
156
150
Jujutsu however, works around this by assigning stable
157
151
"change id"s to each change (which internally point to a git
158
-
commit, if you use the git backing). If you edit an old
159
-
commit, its SHA changes, but its change-id remains the same.
152
+
commit, if you use the git backing). If you edit a commit,
153
+
its SHA changes, but its change-id remains the same.
160
154
161
155
And this is the essence of our new stacked PRs feature!
162
156
···
210
204
<figcaption class="text-center">The "stack" is similar to Gerrit's relation chain</figcaption>
211
205
</figure>
212
206
213
-
After a while, I receive a couple of review comments, but
214
-
not on my entire submission, but rather, on each *individual
207
+
After a while, I receive a couple of review comments, not on
208
+
my entire submission, but rather, on each *individual
215
209
change*. Additionally, the reviewer is happy with my first
216
210
change, and has gone ahead and merged that:
217
211
···
275
269
# hack, hack, hack
276
270
```
277
271
278
-
We are done addressing reviews, let us push our code:
272
+
We are done addressing reviews:
279
273
```
280
274
$ jj git push
281
275
Changes to push to origin:
···
283
277
```
284
278
285
279
Upon resubmitting the PR for review, Tangled is able to
286
-
accurately map every change in the resubmitted branch to its
287
-
original PR, using jujutsu change-ids:
280
+
accurately trace the commit across rewrites, using jujutsu
281
+
change-ids, and map it to the corresponding PR:
288
282
289
283
<div class="flex justify-center items-start gap-2">
290
284
<figure class="w-1/2 m-0 flex flex-col items-center">
static/img/review_difference.jpeg
static/img/review_difference.jpeg
This is a binary file and will not be displayed.
static/img/review_union.jpeg
static/img/review_union.jpeg
This is a binary file and will not be displayed.