jensroemer.com
forked from
tangled.org/site
engineering blog at https://blog.tangled.sh
update intro and closing
anirudh.fi
+30
-13
pages/blog/pulls.md
+30
-13
pages/blog/pulls.md
···
15
15
draft: true
16
16
---
17
17
18
-
We've been having great fun building pull requests. It's a feature we sort of
19
-
take for granted
18
+
We've spent the last few weeks building out a pull request system for Tangled,
19
+
and today we want to lift the hood and show you how it works. What makes our
20
+
implementation particularly interesting is that Tangled is federated --
21
+
repositories can exist across different servers (which we call "knots"). This
22
+
distributed nature creates unique engineering challenges that we had to solve.
20
23
21
-
We figured it would be fun to write about the engineering that went into
22
-
building this, especially because Tangled is federated and Git repos
23
-
can live across different servers (called "knots"). If you're new here,
24
+
If you're new to Tangled and wondering what this knot business is all about,
24
25
[read our intro](/intro) for the full story!
25
26
26
27
Now, on with the show!
···
94
95
</figure>
95
96
96
97
97
-
98
98
## quick detour: what's in a fork?
99
99
100
100
Forks are just "clones" of another repository. They aren't your typical
···
157
157
+refs/heads/main:refs/hidden/feature-1/main
158
158
```
159
159
160
-
Since we already have a remote connection (`origin`, by default) to the original
161
-
repository (remember, we cloned it earlier), we can use `fetch` with this
162
-
refspec to bring the remote `main` branch into our local hidden ref. Each pull
163
-
request gets its own hidden ref, hence the `refs/hidden/:localRef/:remoteRef`
164
-
format. We keep this ref updated whenever you push new commits to your feature
165
-
branch, ensuring that comparisons -- and any potential merge conflicts -- are always
166
-
based on the latest state of the target branch.
160
+
Since we already have a remote (`origin`, by default) to the original repository
161
+
(remember, we cloned it earlier), we can use `fetch` with this refspec to bring
162
+
the remote `main` branch into our local hidden ref. Each pull request gets its
163
+
own hidden ref, hence the `refs/hidden/:localRef/:remoteRef` format. We keep
164
+
this ref updated whenever you push new commits to your feature branch, ensuring
165
+
that comparisons -- and any potential merge conflicts -- are always based on the
166
+
latest state of the target branch.
167
+
168
+
And just like earlier, we produce the patch by diffing your feature branch with
169
+
the hidden tracking ref and do the whole atproto record thing.
170
+
171
+
## future plans
172
+
173
+
To close off this post, we wanted to share some of our future plans for pull requests:
174
+
175
+
* `format-patch` support: both for pasting in the UI and internally. This allows
176
+
us to show commits in the PR page, and offer different merge strategies to
177
+
choose from (squash, rebase, ...).
178
+
179
+
* Gerrit-style `refs/for/main`: we're still hashing out the details but being
180
+
able to push commits to a ref to "auto-create" a PR would be super handy!
181
+
182
+
* Change ID support: This will allow us to group changes together and track them
183
+
across multiple commits, and to provide "history" for each change.