update intro and closing

pages/blog/pulls.md

···
 draft: true
 ---
 
-We've been having great fun building pull requests. It's a feature we sort of
-take for granted
+We've spent the last few weeks building out a pull request system for Tangled,
+and today we want to lift the hood and show you how it works. What makes our
+implementation particularly interesting is that Tangled is federated --
+repositories can exist across different servers (which we call "knots"). This
+distributed nature creates unique engineering challenges that we had to solve.
 
-We figured it would be fun to write about the engineering that went into
-building this, especially because Tangled is federated and Git repos
-can live across different servers (called "knots"). If you're new here,
+If you're new to Tangled and wondering what this knot business is all about,
 [read our intro](/intro) for the full story!
 
 Now, on with the show!
···
 </figure>
 
 
-
 ## quick detour: what's in a fork?
 
 Forks are just "clones" of another repository. They aren't your typical
···
 +refs/heads/main:refs/hidden/feature-1/main
 ```
 
-Since we already have a remote connection (`origin`, by default) to the original
-repository (remember, we cloned it earlier), we can use `fetch` with this
-refspec to bring the remote `main` branch into our local hidden ref. Each pull
-request gets its own hidden ref, hence the `refs/hidden/:localRef/:remoteRef`
-format. We keep this ref updated whenever you push new commits to your feature
-branch, ensuring that comparisons -- and any potential merge conflicts -- are always
-based on the latest state of the target branch.
+Since we already have a remote (`origin`, by default) to the original repository
+(remember, we cloned it earlier), we can use `fetch` with this refspec to bring
+the remote `main` branch into our local hidden ref. Each pull request gets its
+own hidden ref, hence the `refs/hidden/:localRef/:remoteRef` format. We keep
+this ref updated whenever you push new commits to your feature branch, ensuring
+that comparisons -- and any potential merge conflicts -- are always based on the
+latest state of the target branch.
+
+And just like earlier, we produce the patch by diffing your feature branch with
+the hidden tracking ref and do the whole atproto record thing.
+
+## future plans
+
+To close off this post, we wanted to share some of our future plans for pull requests:
+
+* `format-patch` support: both for pasting in the UI and internally. This allows
+us to show commits in the PR page, and offer different merge strategies to
+choose from (squash, rebase, ...).
+
+* Gerrit-style `refs/for/main`: we're still hashing out the details but being
+able to push commits to a ref to "auto-create" a PR would be super handy!
+
+* Change ID support: This will allow us to group changes together and track them
+across multiple commits, and to provide "history" for each change.