+7
-9
pages/blog/stacking.md
+7
-9
pages/blog/stacking.md
···
28
28
29
29
## the diff soup model
30
30
31
-
When you create a PR on traditional code-forges (GitHub
31
+
When you create a PR on traditional code forges (GitHub
32
32
specifically), the UX implicitly encourages you to address
33
33
your code review by *adding commits* on top of your original
34
34
set of changes:
···
37
37
suggestion into your PR
38
38
- GitHub only shows you the diff of all files at once by
39
39
default
40
-
- It is difficult to know what changed across force-pushes
40
+
- It is difficult to know what changed across force pushes
41
41
42
42
Consider a hypothetical PR that adds 3 commits:
43
43
···
96
96
could do this with git if you are familiar with fixup
97
97
commits or interactive rebasing).
98
98
99
-
Lets try that again:
99
+
Let's try that again:
100
100
101
101
```
102
102
[c] implement new feature across the board (HEAD)
···
161
161
162
162
## interdiff code review on tangled
163
163
164
-
To really explain how this works, lets start with a [new
164
+
To really explain how this works, let's start with a [new
165
165
codebase](https://tangled.sh/@oppi.li/stacking-demo/):
166
166
167
167
```
···
249
249
├ my set: introduce basic set operations
250
250
~
251
251
252
-
# lets edit the implementation of `Union`
252
+
# let's edit the implementation of `Union`
253
253
$ jj edit mk
254
254
255
255
# hack, hack, hack
···
268
268
> there is a logic bug here, the condition should be negated.
269
269
270
270
```
271
-
# lets edit the implementation of `Difference`
271
+
# let's edit the implementation of `Difference`
272
272
$ jj edit so
273
273
274
274
# hack, hack, hack
···
358
358
```
359
359
360
360
This feature writes `change-id` headers directly into the
361
-
git commit object, and is visible to code-forges upon push,
361
+
git commit object, and is visible to code forges upon push,
362
362
and allows you to stack your PRs on Tangled.
363
-
364
-