The Lifecycle of a Pull Request

Summary

We’ve spent the last couple of weeks building out a pull request system for Tangled, and today we want to lift the hood and show you how it works. If you’re new to Tangled, read our intro for the full story! You have three options to contribute to a repository: Paste a patch on the web UI Compare two local branches (you’ll see this only if you’re a collaborator on the repo) Compare across forks Whatever you choose, at the core of every PR is the patch. First, you write some code. Then, you run git diff to produce a patch and make everyone’s lives easier, or push to a branch, and we generate it ourselves by comparing against the target. patch generation When you create a PR from a branch, we create a “patch” by calculating the difference between your branch and the target branch. Consider this scenario: A is the merge-base for feature and main. Your feature branch has advanced 2 commits since you first branched out, but in the meanwhile, main has also advanced 2 commits. Doing a trivial git diff feature main will produce a confusing patch: the patch will apply the changes from X and Y the patch will revert the changes from B and C We obviously do not want the second part! To only show the changes added by feature, we have to identify the “merge-base”: the nearest common ancestor of feature and main. In this case, A is the nearest common ancestor, and subsequently, the patch calculated will contain just X and Y. ref comparisons across forks The plumbing described above is easy to do across two branches, but what about forks? And what if they live on different servers altogether (as they can in Tangled!)? Here’s the concept: since we already have all the necessary components to compare two local refs, why not simply “localize” the remote ref? In simpler terms, we instruct Git to fetch the target branch from the original repository and store it in your fork under a special name. This approach allows us to compare your changes against the most current version of the bran...