tangled.org
anirudh.fi
+12
-4
pages/blog/fork-pulls.md
pages/blog/pulls.md
+12
-4
pages/blog/fork-pulls.md
pages/blog/pulls.md
···
1
1
---
2
2
atroot: true
3
3
template:
4
-
slug: fork-pulls
4
+
slug: pulls
5
5
title: the lifecycle of a pull request
6
6
subtitle: We shipped a bunch of PR features recently; here's how we built it
7
7
date: 2025-04-15
···
102
102
103
103
Great, we've got a fork on your knot now. You can now work on your
104
104
change safely here -- but how do you now propose a pull request from
105
-
your fork? And before that, what exactly is a "pull request" anyway?
105
+
your fork?
106
106
107
107
### ref comparisons across forks
108
108
···
111
111
realised that so far, this only works *within* the same repository --
112
112
and not across forks, which is another git repository entirely.
113
113
114
-
We'll admit: we ... omitted some sneaky bits in the forks section above.
115
-
The idea is simple: we already have all the bits needed to compare two
114
+
We'll admit: we ... omitted some sneaky bits about forks earlier. The
115
+
idea is simple: we already have all the pieces needed to compare two
116
116
local refs, so why not just "localize" the remote ref?
117
117
118
118
That's where our hidden tracking refs come in. When you create a pull
···
138
138
whenever you push new commits to your feature branch, ensuring that the
139
139
comparison -- and any potential merge conflicts -- are always based on
140
140
the latest target branch state.
141
+
142
+
143
+
<figure class="max-w-[550px] m-auto flex flex-col items-center justify-center">
144
+
<img class="h-auto max-w-full" src="/static/img/hidden-ref.png">
145
+
<figcaption class="text-center">Hidden tracking ref.</figcaption>
146
+
</figure>
147
+
148
+