comparing 14576995fca8d4cdab64036977e638498af40e98 and master on tangled.org/site

+2

.gitignore

··· 2 2 build/ 3 3 static/tw.css 4 4 *.ttf 5 + *.woff2 5 6 !.gitignore 7 + .DS_Store

+16

.tangled/workflows/deploy.yaml

··· 1 + engine: nixery 2 + when: 3 + - event: ["push", "pull_request"] 4 + branch: ["master"] 5 + 6 + dependencies: 7 + nixpkgs: 8 + - nodejs 9 + 10 + steps: 11 + - name: build site 12 + command: | 13 + nix develop --command bash -c 'vite build' 14 + - name: deploy 15 + command: | 16 + npx --yes wrangler pages deploy --branch master --project-name tangled-blog ./build/

+2 -2

config.yaml

··· 1 1 preBuild: 2 2 - tailwindcss -i input.css -o static/tw.css 3 - title: tangled.sh engineering blog 3 + title: tangled engineering 4 4 # note the trailing slash! 5 - url: "https://tangled.sh" 5 + url: "https://blog.tangled.sh/" 6 6 description: "" 7 7 author: 8 8 name: "Anirudh Oppiliappan"

+31 -20

flake.lock

··· 1 1 { 2 2 "nodes": { 3 - "ia-fonts-src": { 3 + "ibm-plex-mono-src": { 4 4 "flake": false, 5 5 "locked": { 6 - "lastModified": 1686932517, 7 - "narHash": "sha256-2T165nFfCzO65/PIHauJA//S+zug5nUwPcg8NUEydfc=", 8 - "owner": "iaolo", 9 - "repo": "iA-Fonts", 10 - "rev": "f32c04c3058a75d7ce28919ce70fe8800817491b", 11 - "type": "github" 6 + "lastModified": 1731402384, 7 + "narHash": "sha256-OwUmrPfEehLDz0fl2ChYLK8FQM2p0G1+EMrGsYEq+6g=", 8 + "type": "tarball", 9 + "url": "https://github.com/IBM/plex/releases/download/@ibm/plex-mono@1.1.0/ibm-plex-mono.zip" 12 10 }, 13 11 "original": { 14 - "owner": "iaolo", 15 - "repo": "iA-Fonts", 16 - "type": "github" 12 + "type": "tarball", 13 + "url": "https://github.com/IBM/plex/releases/download/@ibm/plex-mono@1.1.0/ibm-plex-mono.zip" 14 + } 15 + }, 16 + "inter-fonts-src": { 17 + "flake": false, 18 + "locked": { 19 + "lastModified": 1731680160, 20 + "narHash": "sha256-5vdKKvHAeZi6igrfpbOdhZlDX2/5+UvzlnCQV6DdqoQ=", 21 + "type": "tarball", 22 + "url": "https://github.com/rsms/inter/releases/download/v4.1/Inter-4.1.zip" 23 + }, 24 + "original": { 25 + "type": "tarball", 26 + "url": "https://github.com/rsms/inter/releases/download/v4.1/Inter-4.1.zip" 17 27 } 18 28 }, 19 29 "nixpkgs": { ··· 48 58 }, 49 59 "root": { 50 60 "inputs": { 51 - "ia-fonts-src": "ia-fonts-src", 61 + "ibm-plex-mono-src": "ibm-plex-mono-src", 62 + "inter-fonts-src": "inter-fonts-src", 52 63 "nixpkgs": "nixpkgs", 53 64 "vite": "vite" 54 65 } ··· 58 69 "nixpkgs": "nixpkgs_2" 59 70 }, 60 71 "locked": { 61 - "lastModified": 1737395755, 62 - "narHash": "sha256-p69EGNDGdCtdKcuu7y8VAC1q2thV5mpEQDs8/N7xliQ=", 63 - "owner": "icyphox", 64 - "repo": "go-vite", 65 - "rev": "589694da6b9c219b6627980ac86d1a6435d0176a", 66 - "type": "github" 72 + "lastModified": 1758224598, 73 + "narHash": "sha256-Ai+kyEpZVPTuk0IP34kE8ZaXxhI+Z97msUFPe82k0Ic=", 74 + "ref": "refs/heads/master", 75 + "rev": "e67e553dc237e41adc9ceae4d834fc02d44e4eb4", 76 + "revCount": 96, 77 + "type": "git", 78 + "url": "https://tangled.sh/@anirudh.fi/vite" 67 79 }, 68 80 "original": { 69 - "owner": "icyphox", 70 - "repo": "go-vite", 71 - "type": "github" 81 + "type": "git", 82 + "url": "https://tangled.sh/@anirudh.fi/vite" 72 83 } 73 84 } 74 85 },

+26 -17

flake.nix

··· 2 2 description = "site"; 3 3 4 4 inputs = { 5 - nixpkgs.url = "github:nixos/nixpkgs"; 6 - vite.url = "github:icyphox/go-vite"; 7 - ia-fonts-src = { 8 - url = "github:iaolo/iA-Fonts"; 9 - flake = false; 10 - }; 5 + nixpkgs.url = "github:nixos/nixpkgs"; 6 + vite = { 7 + url = "git+https://tangled.sh/@anirudh.fi/vite"; 8 + flake = true; 9 + }; 10 + inter-fonts-src = { 11 + url = "https://github.com/rsms/inter/releases/download/v4.1/Inter-4.1.zip"; 12 + flake = false; 13 + }; 14 + ibm-plex-mono-src = { 15 + url = "https://github.com/IBM/plex/releases/download/%40ibm%2Fplex-mono%401.1.0/ibm-plex-mono.zip"; 16 + flake = false; 17 + }; 11 18 }; 12 19 13 20 outputs = 14 21 { self 15 22 , nixpkgs 16 23 , vite 17 - , ia-fonts-src 24 + , inter-fonts-src 25 + , ibm-plex-mono-src 18 26 }: 19 27 let 20 28 supportedSystems = [ ··· 42 50 pkgs.tailwindcss 43 51 ]; 44 52 shellHook = '' 45 - cp -f ${ia-fonts-src}/"iA Writer Quattro"/Static/*.ttf static/fonts/ 46 - cp -f ${ia-fonts-src}/"iA Writer Mono"/Static/*.ttf static/fonts/ 53 + cp -f ${inter-fonts-src}/web/InterVariable*.woff2 static/fonts/ 54 + cp -f ${inter-fonts-src}/web/InterDisplay*.woff2 static/fonts/ 55 + cp -f ${ibm-plex-mono-src}/fonts/complete/woff2/IBMPlexMono-Regular.woff2 static/fonts/ 47 56 ''; 48 57 }; 49 58 } ··· 63 72 ''}/bin/vite-build"; 64 73 cwd = ./.; 65 74 }; 66 - deploy = { 67 - type = "app"; 68 - program = "${pkgs.writeShellScriptBin "s3-sync" '' 69 - #!/usr/bin/env bash 70 - ${vite.packages.${system}.vite}/bin/vite build 71 - ${pkgs.awscli2}/bin/aws s3 sync build s3://site/ --size-only 72 - ''}/bin/s3-sync"; 73 - }; 74 75 serve = { 75 76 type = "app"; 76 77 program = "${pkgs.writeShellScriptBin "vite-serve" '' ··· 87 88 ${vite.packages.${system}.vite}/bin/vite serve & 88 89 find pages/ static/ templates/ | ${pkgs.entr}/bin/entr ${vite.packages.${system}.vite}/bin/vite build --drafts 89 90 ''}/bin/vite-serve"; 91 + }; 92 + deploy = { 93 + type = "app"; 94 + program = "${pkgs.writeShellScriptBin "deploy" '' 95 + #!/usr/bin/env bash 96 + ${vite.packages.${system}.vite}/bin/vite build 97 + ${pkgs.wrangler}/bin/wrangler pages deploy --project-name tangled-blog ./build 98 + ''}/bin/deploy"; 90 99 }; 91 100 } 92 101 );

+60 -72

input.css

··· 3 3 @tailwind utilities; 4 4 @layer base { 5 5 @font-face { 6 - font-family: "iA Writer Quattro S"; 7 - src: url("/static/fonts/iAWriterQuattroS-Regular.ttf") 8 - format("truetype"); 6 + font-family: "InterVariable"; 7 + src: url("/static/fonts/InterVariable.woff2") format("woff2"); 9 8 font-weight: normal; 10 9 font-style: normal; 11 10 font-display: swap; 12 - font-feature-settings: 13 - "calt" 1, 14 - "kern" 1; 15 11 } 12 + 16 13 @font-face { 17 - font-family: "iA Writer Quattro S"; 18 - src: url("/static/fonts/iAWriterQuattroS-Bold.ttf") format("truetype"); 19 - font-weight: bold; 20 - font-style: normal; 21 - font-display: swap; 22 - font-feature-settings: 23 - "calt" 1, 24 - "kern" 1; 25 - } 26 - @font-face { 27 - font-family: "iA Writer Quattro S"; 28 - src: url("/static/fonts/iAWriterQuattroS-Italic.ttf") format("truetype"); 14 + font-family: "InterVariable"; 15 + src: url("/static/fonts/InterVariable-Italic.woff2") format("woff2"); 29 16 font-weight: normal; 30 17 font-style: italic; 31 18 font-display: swap; 32 - font-feature-settings: 33 - "calt" 1, 34 - "kern" 1; 35 19 } 20 + 36 21 @font-face { 37 - font-family: "iA Writer Quattro S"; 38 - src: url("/static/fonts/iAWriterQuattroS-BoldItalic.ttf") 39 - format("truetype"); 22 + font-family: "InterVariable"; 23 + src: url("/static/fonts/InterDisplay-Bold.woff2") format("woff2"); 40 24 font-weight: bold; 41 - font-style: italic; 25 + font-style: normal; 42 26 font-display: swap; 43 - font-feature-settings: 44 - "calt" 1, 45 - "kern" 1; 46 27 } 47 28 48 29 @font-face { 49 - font-family: "iA Writer Mono S"; 50 - src: url("/static/fonts/iAWriterMonoS-Regular.ttf") format("truetype"); 51 - font-weight: normal; 52 - font-style: normal; 30 + font-family: "InterVariable"; 31 + src: url("/static/fonts/InterDisplay-BoldItalic.woff2") format("woff2"); 32 + font-weight: bold; 33 + font-style: italic; 53 34 font-display: swap; 54 - font-feature-settings: 55 - "calt" 1, 56 - "kern" 1; 57 35 } 36 + 58 37 @font-face { 59 - font-family: "iA Writer Mono S"; 60 - src: url("/static/fonts/iAWriterMonoS-Bold.ttf") format("truetype"); 61 - font-weight: bold; 38 + font-family: "IBMPlexMono"; 39 + src: url("/static/fonts/IBMPlexMono-Regular.woff2") format("woff2"); 40 + font-weight: normal; 62 41 font-style: normal; 63 42 font-display: swap; 64 - font-feature-settings: 65 - "calt" 1, 66 - "kern" 1; 67 43 } 44 + 68 45 @font-face { 69 - font-family: "iA Writer Mono S"; 70 - src: url("/static/fonts/iAWriterMonoS-Italic.ttf") format("truetype"); 46 + font-family: "IBMPlexMono"; 47 + src: url("/static/fonts/IBMPlexMono-Italic.woff2") format("woff2"); 71 48 font-weight: normal; 72 49 font-style: italic; 73 50 font-display: swap; 74 - font-feature-settings: 75 - "calt" 1, 76 - "kern" 1; 77 51 } 52 + 78 53 @font-face { 79 - font-family: "iA Writer Mono S"; 80 - src: url("/static/fonts/iAWriterMonoS-BoldItalic.ttf") 81 - format("truetype"); 54 + font-family: "IBMPlexMono"; 55 + src: url("/static/fonts/IBMPlexMono-Bold.woff2") format("woff2"); 82 56 font-weight: bold; 83 - font-style: italic; 57 + font-style: normal; 84 58 font-display: swap; 85 - font-feature-settings: 86 - "calt" 1, 87 - "kern" 1; 88 59 } 89 60 90 61 @font-face { 91 - font-family: "Inter"; 92 - font-style: normal; 93 - font-weight: 400; 62 + font-family: "IBMPlexMono"; 63 + src: url("/static/fonts/IBMPlexMono-BoldItalic.woff2") format("woff2"); 64 + font-weight: bold; 65 + font-style: italic; 94 66 font-display: swap; 95 - font-feature-settings: 96 - "calt" 1, 97 - "kern" 1; 98 67 } 68 + 99 69 h1 { 100 70 @apply text-2xl; 101 - @apply font-sans; 102 71 @apply text-black; 103 72 @apply font-bold; 104 73 } 105 74 106 75 ::selection { 107 - @apply bg-yellow-400; 108 - @apply text-black; 109 - @apply bg-opacity-30; 110 - } 111 - 112 - html { 113 - letter-spacing: -0.01em; 114 - word-spacing: -0.07em; 76 + @apply bg-yellow-400 text-black bg-opacity-30 dark:bg-yellow-600 dark:bg-opacity-50 dark:text-white; 115 77 } 116 78 117 79 @layer base { 80 + html { 81 + font-size: 14px; 82 + scrollbar-gutter: stable; 83 + } 84 + @supports (font-variation-settings: normal) { 85 + html { 86 + font-feature-settings: 87 + "ss01" 1, 88 + "kern" 1, 89 + "liga" 1, 90 + "cv05" 1, 91 + "tnum" 1; 92 + } 93 + } 94 + 118 95 a { 119 - @apply no-underline text-black hover:underline hover:text-gray-800; 96 + @apply no-underline text-black hover:underline hover:text-gray-800 dark:text-white dark:hover:text-gray-300; 97 + } 98 + 99 + img { 100 + @apply border border-gray-200 rounded dark:border-gray-700; 101 + } 102 + 103 + img.icon { 104 + @apply border-0 dark:brightness-100 dark:opacity-100; 120 105 } 121 106 122 107 label { 123 - @apply block text-sm text-black; 108 + @apply block mb-2 text-gray-900 text-sm font-bold py-2 uppercase dark:text-gray-100; 124 109 } 125 110 input { 126 - @apply bg-white border border-black rounded-sm focus:ring-black p-2; 111 + @apply bg-white border border-gray-400 rounded-sm focus:ring-black p-3 dark:bg-gray-800 dark:border-gray-600 dark:text-white dark:focus:ring-gray-400; 127 112 } 128 113 textarea { 129 - @apply bg-white border border-black rounded-sm focus:ring-black p-2; 114 + @apply bg-white border border-gray-400 rounded-sm focus:ring-black p-3 dark:bg-gray-800 dark:border-gray-600 dark:text-white dark:focus:ring-gray-400; 115 + } 116 + details summary::-webkit-details-marker { 117 + display: none; 130 118 } 131 119 } 132 120

+5

pages/_index.md

··· 1 + --- 2 + template: index.html 3 + title: tangled engineering 4 + subtitle: all the ropes and scaffolding 5 + ---

+3

pages/_redirects

··· 1 + /blog/ / 200 2 + /blog/feed.xml /blog/feed.xml 200 3 + /blog/* /:splat

+160

pages/blog/6-months.md

··· 1 + --- 2 + atroot: true 3 + template: 4 + slug: 6-months 5 + title: 6 months of Tangled 6 + subtitle: a quick recap, and notes on the future 7 + date: 2025-10-21 8 + image: /static/img/6-months.png 9 + authors: 10 + - name: Anirudh 11 + email: anirudh@tangled.org 12 + handle: anirudh.fi 13 + - name: Akshay 14 + email: akshay@tangled.org 15 + handle: oppi.li 16 + draft: false 17 + --- 18 + 19 + Hello Tanglers! It's been over 6 months since we first announced 20 + Tangled, so we figured we'd do a quick retrospective of what we built so 21 + far and what's next. 22 + 23 + If you're new here, here's a quick overview: Tangled is a git hosting 24 + and collaboration platform built on top of the [AT 25 + Protocol](https://atproto.com). You can read a bit more about our 26 + architecture [here](/intro). 27 + 28 + ## new logo and mascot: dolly! 29 + 30 + Tangled finally has a logo! Designed by Akshay himself, Dolly is in 31 + reference to the first ever *cloned* mammal. For a full set of brand assets and guidelines, see our new [branding page](https://tangled.org/brand). 32 + 33 + ![logo with text](/static/img/logo_with_text.jpeg) 34 + 35 + With that, let's recap the major platform improvements so far! 36 + 37 + ## pull requests: doubling down on jujutsu 38 + 39 + One of the first major features we built was our [pull requests 40 + system](/pulls), which follows a unique round-based submission & review 41 + approach. This was really fun to innovate on -- it remains one of 42 + Tangled's core differentiators, and one we plan to keep improving. 43 + 44 + In the same vein, we're the first ever code forge to support [stacking 45 + pull requests](/stacking) using Jujutsu! We're big fans of the tool and 46 + we use it everyday as we hack on 47 + [tangled.org/core](https://tangled.org/@tangled.org/core). 48 + 49 + Ultimately, we think PR-based collaboration should evolve beyond the 50 + traditional model, and we're excited to keep experimenting with new 51 + ideas that make code review and contribution easier! 52 + 53 + ## spindle 54 + 55 + CI was our most requested feature, and we spent a *lot* of time debating 56 + how to approach it. We considered integrating with existing platforms, 57 + but none were good fits. So we gave in to NIH and [built spindle 58 + ourselves](/ci)! This allowed us to go in on Nix using Nixery to build 59 + CI images on the fly and cache them. 60 + 61 + Spindle is still early but designed to be extensible and is AT-native. 62 + The current Docker/Nixery-based engine is limiting -- we plan to switch 63 + to micro VMs down the line to run full-fledged NixOS (and other base 64 + images). Meanwhile, if you've got ideas for other spindle backends 65 + (Kubernetes?!), we'd love to [hear from you](https://chat.tangled.org). 66 + 67 + ## XRPC APIs 68 + 69 + We introduced a complete migration of the knotserver to an 70 + [XRPC](https://atproto.com/specs/xrpc) API. Alongside this, we also 71 + decoupled the knot from the appview by getting rid of the registration 72 + secret, which was centralizing. Knots (and spindles) simply declare 73 + their owner, and any appview can verify ownership. Once we stabilize the 74 + [lexicon definitions](lexicons) for these XRPC calls, building clients 75 + for knots, or alternate implementations should become much simpler. 76 + 77 + [lexicons]: https://tangled.sh/@tangled.sh/core/tree/master/lexicons 78 + 79 + ## issues rework 80 + 81 + Issues got a major rework (and facelift) too! They are now threaded: 82 + top-level comments with replies. This makes Q/A style discussions much 83 + easier to follow! 84 + 85 + ![issue thread](/static/img/issue-threading.webp) 86 + 87 + ## hosted PDS 88 + 89 + A complaint we often recieved was the need for a Bluesky account to use 90 + Tangled; and besides, we realised that the overlap between Bluesky users 91 + and possible Tangled users only goes so far -- we aim to be a generic 92 + code forge after all, AT just happens to be an implementation 93 + detail. 94 + 95 + To address this, we spun up the tngl.sh PDS hosted right here in 96 + Finland. The only way to get an account on this PDS is by [signing 97 + up](https://tangled.sh/signup). There's a lot we can do to improve this 98 + experience as a generic PDS host, but we're still working out details 99 + around that. 100 + 101 + ## labels 102 + 103 + You can easily categorize issues and pulls via labels! There is plenty 104 + of customization available: 105 + 106 + - labels can be basic, or they can have a key and value set, for example: 107 + `wontfix` or `priority/high` 108 + - labels can be constrained to a set of values: `priority: [high medium low]` 109 + - there can be multiple labels of a given type: `reviewed-by: @oppi.li`, 110 + `reviewed-by: @anirudh.fi` 111 + 112 + The options are endless! You can access them via your repo's settings page. 113 + 114 + <div class="flex justify-center items-center gap-2"> 115 + <figure class="w-full m-0 flex flex-col items-center"> 116 + <a href="static/img/labels_vignette.webp"> 117 + <img class="my-1 w-full h-auto cursor-pointer" src="static/img/labels_vignette.webp" alt="A set of labels applied to an issue."> 118 + </a> 119 + <figcaption class="text-center">A set of labels applied to an issue.</figcaption> 120 + </figure> 121 + 122 + <figure class="w-1/3 m-0 flex flex-col items-center"> 123 + <a href="static/img/new_label_modal.png"> 124 + <img class="my-1 w-full h-auto cursor-pointer" src="static/img/new_label_modal.png" alt="Create custom key-value type labels."> 125 + </a> 126 + <figcaption class="text-center">Create custom key-value type labels.</figcaption> 127 + </figure> 128 + </div> 129 + 130 + 131 + ## notifications 132 + 133 + In-app notifications now exist! You get notifications for a variety of events now: 134 + 135 + * new issues/pulls on your repos (also for collaborators) 136 + * comments on your issues/pulls (also for collaborators) 137 + * close/reopen (or merge) of issues/pulls 138 + * new stars 139 + * new follows 140 + 141 + All of this can be fine-tuned in [/settings/notifications](https://tangled.org/settings/notifications). 142 + 143 + ![notifications](static/img/notifications.png) 144 + 145 + 146 + ## the future 147 + 148 + We're working on a *lot* of exciting new things and possibly some big 149 + announcements to come. Be on the lookout for: 150 + 151 + * email notifications 152 + * preliminary support for issue and PR search 153 + * total "atprotation" [^1] -- the last two holdouts here are repo and pull records 154 + * total federation -- i.e. supporting third-party appviews by making it 155 + reproducible 156 + * achieve complete independence from Bluesky PBC by hosting our own relay 157 + 158 + That's all for now; we'll see you in the atmosphere! Meanwhile, if you'd like to contribute to projects on Tangled, make sure to check out the [good first issues page](https://tangled.org/goodfirstissues) to get started! 159 + 160 + [^1]: atprotation implies a two-way sync between the PDS and appview. Currently, pull requests and repositories are not ingested -- so writing/updating either records on your PDS will not show up on the appview.

+214

pages/blog/ci.md

··· 1 + --- 2 + atroot: true 3 + template: 4 + slug: ci 5 + title: introducing spindle 6 + subtitle: tangled's new CI runner is now generally available 7 + date: 2025-08-06 8 + authors: 9 + - name: Anirudh 10 + email: anirudh@tangled.sh 11 + handle: icyphox.sh 12 + - name: Akshay 13 + email: akshay@tangled.sh 14 + handle: oppi.li 15 + --- 16 + 17 + Since launching Tangled, continuous integration has 18 + consistently topped our feature request list. Today, CI is 19 + no longer a wishlist item, but a fully-featured reality. 20 + 21 + Meet **spindle**: Tangled's new CI runner built atop Nix and 22 + AT Protocol. In typical Tangled fashion we've been 23 + dogfooding spindle for a while now; this very blog post 24 + you're reading was [built and published using 25 + spindle](https://tangled.sh/@tangled.sh/site/pipelines/452/workflow/deploy.yaml). 26 + 27 + Tangled is a new social-enabled Git collaboration platform, 28 + [read our intro](/intro) for more about the project. 29 + 30 + ![spindle architecture](/static/img/spindle-arch.png) 31 + 32 + ## how spindle works 33 + 34 + Spindle is designed around simplicity and the decentralized 35 + nature of the AT Protocol. In ingests "pipeline" records and 36 + emits job status updates. 37 + 38 + When you push code or open a pull request, the knot hosting 39 + your repository emits a pipeline event 40 + (`sh.tangled.pipeline`). Running as a dedicated service, 41 + spindle subscribes to these events via websocket connections 42 + to your knot. 43 + 44 + Once triggered, spindle reads your pipeline manifest, spins 45 + up the necessary execution environment (covered below), and 46 + runs your defined workflow steps. Throughout execution, it 47 + streams real-time logs and status updates 48 + (`sh.tangled.pipeline.status`) back through websockets, 49 + which the Tangled appview subscribes to for live updates. 50 + 51 + Over at the appview, these updates are ingested and stored, 52 + and logs are streamed live. 53 + 54 + ## spindle pipelines 55 + 56 + The pipeline manifest is defined in YAML, and should be 57 + relatively familiar to those that have used other CI 58 + solutions. Here's a minimal example: 59 + 60 + ```yaml 61 + # test.yaml 62 + 63 + when: 64 + - event: ["push", "pull_request"] 65 + branch: ["master"] 66 + 67 + dependencies: 68 + nixpkgs: 69 + - go 70 + 71 + steps: 72 + - name: run all tests 73 + environment: 74 + CGO_ENABLED: 1 75 + command: | 76 + go test -v ./... 77 + ``` 78 + 79 + You can read the [full manifest spec 80 + here](https://tangled.sh/@tangled.sh/core/blob/master/docs/spindle/pipeline.md), 81 + but the `dependencies` block is the real interesting bit. 82 + Dependencies for your workflow, like Go, Node.js, Python 83 + etc. can be pulled in from nixpkgs. 84 + [Nixpkgs](https://github.com/nixos/nixpkgs/) -- for the 85 + uninitiated -- is a vast collection of packages for the Nix 86 + package manager. Fortunately, you needn't know nor care 87 + about Nix to use it! Just head to https://search.nixos.org 88 + to find your package of choice (I'll bet 1€ that it's 89 + there[^1]), toss it in the list and run your build. The 90 + Nix-savvy of you lot will be happy to know that you can use 91 + custom registries too. 92 + 93 + [^1]: I mean, if it isn't there, it's nowhere. 94 + 95 + Workflow manifests are intentionally simple. We do not want 96 + to include a "marketplace" of workflows or complex job 97 + orchestration. The bulk of the work should be offloaded to a 98 + build system, and CI should be used simply for finishing 99 + touches. That being said, this is still the first revision 100 + for CI, there is a lot more on the roadmap! 101 + 102 + Let's take a look at how spindle executes workflow steps. 103 + 104 + ## workflow execution 105 + 106 + At present, the spindle "engine" supports just the Docker 107 + backend[^2]. Podman is known to work with the Docker socket 108 + feature enabled. Each step is run in a separate container, 109 + with the `/tangled/workspace` and `/nix` volumes persisted 110 + across steps. 111 + 112 + [^2]: Support for additional backends like Firecracker are 113 + planned. Contributions welcome! 114 + 115 + The container image is built using 116 + [Nixery](https://nixery.dev). Nixery is a nifty little tool 117 + that takes a path-separated set of Nix packages and returns 118 + an OCI image with each package in a separate layer. Try this 119 + in your terminal if you've got Docker installed: 120 + 121 + ``` 122 + docker run nixery.dev/bash/hello-go hello-go 123 + ``` 124 + 125 + This should output `Hello, world!`. This is running the 126 + [hello-go](https://search.nixos.org/packages?channel=25.05&show=hello-go) 127 + package from nixpkgs. 128 + 129 + Nixery is super handy since we can construct these images 130 + for CI environments on the fly, with all dependencies baked 131 + in, and the best part: caching for commonly used packages is 132 + free thanks to Docker (pre-existing layers get reused). We 133 + run a Nixery instance of our own at 134 + https://nixery.tangled.sh but you may override that if you 135 + choose to. 136 + 137 + ## debugging CI 138 + 139 + We understand that debugging CI can be the worst. There are 140 + two parts to this problem: 141 + 142 + - CI services often bring their own workflow definition 143 + formats and it can sometimes be difficult to know why the 144 + workflow won't run or why the workflow definition is 145 + incorrect 146 + - The CI job itself fails, but this has more to do with the 147 + build system of choice 148 + 149 + To mend the first problem: we are making use of git 150 + [push-options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--ooption). 151 + When you push to a repository with an option like so: 152 + 153 + ``` 154 + git push origin master -o verbose-ci 155 + ``` 156 + 157 + The server runs a basic set of analysis rules on your 158 + workflow file, and reports any errors: 159 + 160 + ``` 161 + λ git push origin main -o verbose-ci 162 + . 163 + . 164 + . 165 + . 166 + remote: error: failed to parse workflow(s): 167 + remote: - at .tangled/workflows/fmt.yml: yaml: line 14: did not find expected key 168 + remote: 169 + remote: warning(s) on pipeline: 170 + remote: - at build.yml: workflow skipped: did not match trigger push 171 + ``` 172 + 173 + The analysis performed at the moment is quite basic (expect 174 + it to get better over time), but it is already quite useful 175 + to help debug workflows that don't trigger! 176 + 177 + ## pipeline secrets 178 + 179 + Secrets are a bit tricky since atproto has no notion of 180 + private data. Secrets are instead written directly from the 181 + appview to the spindle instance using [service 182 + auth](https://docs.bsky.app/docs/api/com-atproto-server-get-service-auth). 183 + In essence, the appview makes a signed request using the 184 + logged-in user's DID key; spindle verifies this signature by 185 + fetching the public key from the DID document. 186 + 187 + ![pipeline secrets](/static/img/pipeline-secrets.png) 188 + 189 + The secrets themselves are stored in a secret manager. By 190 + default, this is the same sqlite database that spindle uses. 191 + This is *fine* for self-hosters. The hosted, flagship 192 + instance at https://spindle.tangled.sh however uses 193 + [OpenBao](https://openbao.org), an OSS fork of HashiCorp 194 + Vault. 195 + 196 + ## get started now 197 + 198 + You can run your own spindle instance pretty easily: the 199 + [spindle self-hosting 200 + guide](https://tangled.sh/@tangled.sh/core/blob/master/docs/spindle/hosting.md) 201 + should have you covered. Once done, head to your 202 + repository's settings tab and set it up! Doesn't work? Feel 203 + free to pop into [Discord](https://chat.tangled.sh) to get 204 + help -- we have a nice little crew that's always around to 205 + help. 206 + 207 + All Tangled users have access to our hosted spindle 208 + instance, free of charge[^3]. You don't have any more 209 + excuses to not migrate to Tangled now -- [get 210 + started](https://tangled.sh/login) with your AT Protocol 211 + account today. 212 + 213 + [^3]: We can't promise we won't charge for it at some point 214 + but there will always be a free tier.

+42 -12

pages/blog/intro.md

··· 4 4 slug: intro 5 5 title: introducing tangled 6 6 subtitle: a git collaboration platform, built on atproto 7 - date: 2025-02-27 8 - draft: true 7 + date: 2025-03-02 8 + authors: 9 + - name: Anirudh 10 + email: anirudh@tangled.sh 11 + handle: icyphox.sh 9 12 --- 10 13 11 14 12 - [Tangled](https://tangled.sh) is a new social-enabled Git collaboration platform, built on top of the [AT Protocol](https://atproto.com). We envision a place where developers have complete ownership of their code, open source communities can freely self-govern and most importantly, coding can be social and fun again. 15 + [Tangled](https://tangled.sh) is a new social-enabled Git collaboration 16 + platform, built on top of the [AT Protocol](https://atproto.com). We 17 + envision a place where developers have complete ownership of their code, 18 + open source communities can freely self-govern and most importantly, 19 + coding can be social and fun again. 13 20 14 - There are several models for decentralized social networks, ranging from ActivityPub's federated model, to Radicle's entirely P2P model. Our approach attempts to be the best of both worlds by adopting atproto -- a protocol for building decentralized social applications with a central identity. 21 + There are several models for decentralized code collaboration platforms, 22 + ranging from ActivityPub's (Forgejo) federated model, to Radicle's 23 + entirely P2P model. Our approach attempts to be the best of both worlds 24 + by adopting atproto -- a protocol for building decentralized social 25 + applications with a central identity. 15 26 16 27 ![tangled architecture](/static/img/arch.svg) 17 28 18 - Our addition to this model is the idea of "knots". Knots are lightweight, headless servers that enable users to host git repositories with ease. Knots are designed for either single or multi-tenant use which is perfect for "community" servers. By default, Tangled provides managed knots where you can host your repositories for free. 29 + Our approach to this is the idea of "knots". Knots are lightweight, 30 + headless servers that enable users to host Git repositories with ease. 31 + Knots are designed for either single or multi-tenant use which is 32 + perfect for self-hosting on a Raspberry Pi at home, or larger 33 + "community" servers. By default, Tangled provides managed knots where 34 + you can host your repositories for free. 19 35 20 - The [App View][appview] at [tangled.sh](https://tangled.sh) acts as a consolidated "view" into the whole network, allowing users to access, clone and contribute to repositories hosted across different knots -- completely seamlessly. 36 + The [App View][appview] at [tangled.sh](https://tangled.sh) acts as a 37 + consolidated "view" into the whole network, allowing users to access, 38 + clone and contribute to repositories hosted across different knots -- 39 + completely seamlessly. 21 40 22 - Tangled is still in its infancy, and we're still building out several of its core features as we dogfood it ourselves. We developed these three core tenets to guide our decisions: 41 + Tangled is still in its infancy, and we're building out several of its 42 + core features as we [dogfood it ourselves][dogfood]. We developed these 43 + three tenets to guide our decisions: 23 44 24 - 1. **Ownership of data** 25 - 2. **Low barrier to entry** 26 - 3. **No compromise on user-experience** 45 + 1. Ownership of data 46 + 2. Low barrier to entry 47 + 3. No compromise on user-experience 27 48 28 - Collaborating on code isn't easy, and the tools and workflows we use should feel natural and stay out of the way. Tangled's architecture enables common workflows to work as you'd expect, while remaining decentralized. 49 + Collaborating on code isn't easy, and the tools and workflows we use 50 + should feel natural and stay out of the way. Tangled's architecture 51 + enables common workflows to work as you'd expect, all while remaining 52 + decentralized. 29 53 30 - We believe that atproto has greatly simplfied one of the hardest parts of social media: having your friends on it. We're rolling out invite-only access to Tangled -- join us on IRC and we'll get you set up. 54 + We believe that atproto has greatly simplfied one of the hardest parts 55 + of social media: having your friends on it. Today, we're rolling out 56 + invite-only access to Tangled -- join us on IRC at `#tangled` on 57 + [libera.chat](https://libera.chat) and we'll get you set up. 31 58 59 + **Update**: Tangled is open to public, simply login at 60 + [tangled.sh/login](https://tangled.sh/login)! Have fun! 32 61 33 62 [pds]: https://atproto.com/guides/glossary#pds-personal-data-server 34 63 [appview]: https://docs.bsky.app/docs/advanced-guides/federation-architecture#app-views 64 + [dogfood]: https://tangled.sh/@tangled.sh/core

+195

pages/blog/pulls.md

··· 1 + --- 2 + atroot: true 3 + template: 4 + slug: pulls 5 + title: the lifecycle of a pull request 6 + subtitle: we shipped a bunch of PR features recently; here's how we built it 7 + date: 2025-04-16 8 + image: /static/img/hidden-ref.png 9 + authors: 10 + - name: Anirudh 11 + email: anirudh@tangled.sh 12 + handle: icyphox.sh 13 + - name: Akshay 14 + email: akshay@tangled.sh 15 + handle: oppili.bsky.social 16 + draft: false 17 + --- 18 + 19 + We've spent the last couple of weeks building out a pull 20 + request system for Tangled, and today we want to lift the 21 + hood and show you how it works. 22 + 23 + If you're new to Tangled, [read our intro](/intro) for the 24 + full story! 25 + 26 + You have three options to contribute to a repository: 27 + 28 + - Paste a patch on the web UI 29 + - Compare two local branches (you'll see this only if you're a 30 + collaborator on the repo) 31 + - Compare across forks 32 + 33 + Whatever you choose, at the core of every PR is the patch. 34 + First, you write some code. Then, you run `git diff` to 35 + produce a patch and make everyone's lives easier, or push to 36 + a branch, and we generate it ourselves by comparing against 37 + the target. 38 + 39 + ## patch generation 40 + 41 + When you create a PR from a branch, we create a "patch" by 42 + calculating the difference between your branch and the 43 + target branch. Consider this scenario: 44 + 45 + <figure class="max-w-[550px] m-auto flex flex-col items-center justify-center"> 46 + <img class="h-auto max-w-full" src="/static/img/merge-base.png"> 47 + <figcaption class="text-center"><code>A</code> is the merge-base for 48 + <code>feature</code> and <code>main</code>.</figcaption> 49 + </figure> 50 + 51 + Your `feature` branch has advanced 2 commits since you first 52 + branched out, but in the meanwhile, `main` has also advanced 53 + 2 commits. Doing a trivial `git diff feature main` will 54 + produce a confusing patch: 55 + 56 + - the patch will apply the changes from `X` and `Y` 57 + - the patch will **revert** the changes from `B` and `C` 58 + 59 + We obviously do not want the second part! To only show the 60 + changes added by `feature`, we have to identify the 61 + "merge-base": the nearest common ancestor of `feature` and 62 + `main`. 63 + 64 + 65 + In this case, `A` is the nearest common ancestor, and 66 + subsequently, the patch calculated will contain just `X` and 67 + `Y`. 68 + 69 + ### ref comparisons across forks 70 + 71 + The plumbing described above is easy to do across two 72 + branches, but what about forks? And what if they live on 73 + different servers altogether (as they can in Tangled!)? 74 + 75 + Here's the concept: since we already have all the necessary 76 + components to compare two local refs, why not simply 77 + "localize" the remote ref? 78 + 79 + In simpler terms, we instruct Git to fetch the target branch 80 + from the original repository and store it in your fork under 81 + a special name. This approach allows us to compare your 82 + changes against the most current version of the branch 83 + you're trying to contribute to, all while remaining within 84 + your fork. 85 + 86 + <figure class="max-w-[550px] m-auto flex flex-col items-center justify-center"> 87 + <img class="h-auto max-w-full" src="/static/img/hidden-ref.png"> 88 + <figcaption class="text-center">Hidden tracking ref.</figcaption> 89 + </figure> 90 + 91 + We call this a "hidden tracking ref." When you create a pull 92 + request from a fork, we establish a refspec that tracks the 93 + remote branch, which we then use to generate a diff. A 94 + refspec is essentially a rule that tells Git how to map 95 + references between a remote and your local repository during 96 + fetch or push operations. 97 + 98 + For example, if your fork has a feature branch called 99 + `feature-1`, and you want to make a pull request to the 100 + `main` branch of the original repository, we fetch the 101 + remote `main` into a local hidden ref using a refspec like 102 + this: 103 + 104 + ``` 105 + +refs/heads/main:refs/hidden/feature-1/main 106 + ``` 107 + 108 + Since we already have a remote (`origin`, by default) to the 109 + original repository (remember, we cloned it earlier), we can 110 + use `fetch` with this refspec to bring the remote `main` 111 + branch into our local hidden ref. Each pull request gets its 112 + own hidden ref, hence the `refs/hidden/:localRef/:remoteRef` 113 + format. We keep this ref updated whenever you push new 114 + commits to your feature branch, ensuring that comparisons -- 115 + and any potential merge conflicts -- are always based on the 116 + latest state of the target branch. 117 + 118 + And just like earlier, we produce the patch by diffing your 119 + feature branch with the hidden tracking ref. Also, the entire pull 120 + request is stored as [an atproto record][atproto-record] and updated 121 + each time the patch changes. 122 + 123 + [atproto-record]: https://pdsls.dev/at://did:plc:qfpnj4og54vl56wngdriaxug/sh.tangled.repo.pull/3lmwniim2i722 124 + 125 + Neat, now that we have a patch; we can move on the hard 126 + part: code review. 127 + 128 + 129 + ## your patch does the rounds 130 + 131 + Tangled uses a "round-based" review format. Your initial 132 + submission starts "round 0". Once your submission receives 133 + scrutiny, you can address reviews and resubmit your patch. 134 + This resubmission starts "round 1". You keep whittling on 135 + your patch till it is good enough, and eventually merged (or 136 + closed if you are unlucky). 137 + 138 + <figure class="max-w-[700px] m-auto flex flex-col items-center justify-center"> 139 + <img class="h-auto max-w-full" src="/static/img/patch-pr-main.png"> 140 + <figcaption class="text-center">A new pull request with a couple 141 + rounds of reviews.</figcaption> 142 + </figure> 143 + 144 + Rounds are a far superior to standard branch-based 145 + approaches: 146 + 147 + - Submissions are immutable: how many times have your 148 + reviews gone out-of-date because the author pushed commits 149 + _during_ your review? 150 + - Reviews are attached to submissions: at a glance, it is 151 + easy to tell which comment applies to which "version" of 152 + the pull-request 153 + - The author can choose when to resubmit! They can commit as 154 + much as they want to their branch, but a new round begins 155 + when they choose to hit "resubmit" 156 + - It is possible to "interdiff" and observe changes made 157 + across submissions (this is coming very soon to Tangled!) 158 + 159 + This [post by Mitchell 160 + Hashimoto](https://mitchellh.com/writing/github-changesets) 161 + goes into further detail on what can be achieved with 162 + round-based reviews. 163 + 164 + ## future plans 165 + 166 + To close off this post, we wanted to share some of our 167 + future plans for pull requests: 168 + 169 + * `format-patch` support: both for pasting in the UI and 170 + internally. This allows us to show commits in the PR page, 171 + and offer different merge strategies to choose from 172 + (squash, rebase, ...). 173 + **Update 2025-08-12**: We have format-patch support! 174 + 175 + * Gerrit-style `refs/for/main`: we're still hashing out the 176 + details but being able to push commits to a ref to 177 + "auto-create" a PR would be super handy! 178 + 179 + * Change ID support: This will allow us to group changes 180 + together and track them across multiple commits, and to 181 + provide "history" for each change. This works great with [Jujutsu][jj]. 182 + **Update 2025-08-12**: This has now landed: https://blog.tangled.sh/stacking 183 + 184 + Join us on [Discord](https://chat.tangled.sh) or 185 + `#tangled` on libera.chat (the two are bridged, so we will 186 + never miss a message!). We are always available to help 187 + setup knots, listen to feedback on features, or even 188 + shepherd contributions! 189 + 190 + **Update 2025-08-12**: We move fast, and we now have jujutsu support, and an 191 + early in-house CI: https://blog.tangled.sh/ci. You no longer need a Bluesky 192 + account to sign-up; head to https://tangled.sh/signup and sign up with your 193 + email! 194 + 195 + [jj]: https://jj-vcs.github.io/jj/latest/

+351

pages/blog/stacking.md

··· 1 + --- 2 + atroot: true 3 + template: 4 + slug: stacking 5 + title: jujutsu on tangled 6 + subtitle: tangled now supports jujutsu change-ids! 7 + date: 2025-06-02 8 + image: /static/img/interdiff_difference.jpeg 9 + authors: 10 + - name: Akshay 11 + email: akshay@tangled.sh 12 + handle: oppi.li 13 + draft: false 14 + --- 15 + 16 + Jujutsu is built around structuring your work into 17 + meaningful commits. Naturally, during code-review, you'd 18 + expect reviewers to be able to comment on individual 19 + commits, and also see the evolution of a commit over time, 20 + as reviews are addressed. We set out to natively support 21 + this model of code-review on Tangled. 22 + 23 + Tangled is a new social-enabled Git collaboration platform, 24 + [read our intro](/intro) for more about the project. 25 + 26 + For starters, I would like to contrast the two schools of 27 + code-review, the "diff-soup" model and the interdiff model. 28 + 29 + ## the diff-soup model 30 + 31 + When you create a PR on traditional code forges (GitHub 32 + specifically), the UX implicitly encourages you to address 33 + your code review by *adding commits* on top of your original 34 + set of changes: 35 + 36 + - GitHub's "Apply Suggestion" button directly commits the 37 + suggestion into your PR 38 + - GitHub only shows you the diff of all files at once by 39 + default 40 + - It is difficult to know what changed across force pushes 41 + 42 + Consider a hypothetical PR that adds 3 commits: 43 + 44 + ``` 45 + [c] implement new feature across the board (HEAD) 46 + | 47 + [b] introduce new feature 48 + | 49 + [a] some small refactor 50 + ``` 51 + 52 + And when only newly added commits are easy to review, this 53 + is what ends up happening: 54 + 55 + ``` 56 + [f] formatting & linting (HEAD) 57 + | 58 + [e] update name of new feature 59 + | 60 + [d] fix bug in refactor 61 + | 62 + [c] implement new feature across the board 63 + | 64 + [b] introduce new feature 65 + | 66 + [a] some small refactor 67 + ``` 68 + 69 + It is impossible to tell what addresses what at a glance, 70 + there is an implicit relation between each change: 71 + 72 + ``` 73 + [f] formatting & linting 74 + | 75 + [e] update name of new feature -------------. 76 + | | 77 + [d] fix bug in refactor -----------. | 78 + | | | 79 + [c] implement new feature across the board | 80 + | | | 81 + [b] introduce new feature <-----------------' 82 + | | 83 + [a] some small refactor <----------' 84 + ``` 85 + 86 + This has the downside of clobbering the output of `git 87 + blame` (if there is a bug in the new feature, you will first 88 + land on `e`, and upon digging further, you will land on 89 + `b`). This becomes incredibly tricky to navigate if reviews 90 + go on through multiple cycles. 91 + 92 + 93 + ## the interdiff model 94 + 95 + With jujutsu however, you have the tools at hand to 96 + fearlessly edit, split, squash and rework old commits (you 97 + can absolutely achieve this with git and interactive 98 + rebasing, but it is certainly not trivial). 99 + 100 + Let's try that again: 101 + 102 + ``` 103 + [c] implement new feature across the board (HEAD) 104 + | 105 + [b] introduce new feature 106 + | 107 + [a] some small refactor 108 + ``` 109 + 110 + To fix the bug in the refactor: 111 + 112 + ``` 113 + $ jj edit a 114 + Working copy (@) now at: [a] some small refactor 115 + 116 + $ # hack hack hack 117 + 118 + $ jj log -r a:: 119 + Rebased 2 descendant commits onto updated working copy 120 + [c] implement new feature across the board (HEAD) 121 + | 122 + [b] introduce new feature 123 + | 124 + [a] some small refactor 125 + ``` 126 + 127 + Jujutsu automatically rebases the descendants without having 128 + to lift a finger. Brilliant! You can repeat the same 129 + exercise for all review comments, and effectively, your 130 + PR will have evolved like so: 131 + 132 + ``` 133 + a -> b -> c initial attempt 134 + | | | 135 + v v v 136 + a' -> b' -> c' after first cycle of reviews 137 + ``` 138 + 139 + ## the catch 140 + 141 + If you use `git rebase`, you will know that it modifies 142 + history and therefore changes the commit SHA. How then, 143 + should one tell the difference between the "old" and "new" 144 + state of affairs? 145 + 146 + Tools like `git-range-diff` make use of a variety of 147 + text-based heuristics to roughly match `a` to `a'` and `b` 148 + to `b'` etc. 149 + 150 + Jujutsu however, works around this by assigning stable 151 + "change id"s to each change (which internally point to a git 152 + commit, if you use the git backing). If you edit a commit, 153 + its SHA changes, but its change-id remains the same. 154 + 155 + And this is the essence of our new stacked PRs feature! 156 + 157 + ## interdiff code review on tangled 158 + 159 + To really explain how this works, let's start with a [new 160 + codebase](https://tangled.sh/@oppi.li/stacking-demo/): 161 + 162 + ``` 163 + $ jj git init --colocate 164 + 165 + # -- initialize codebase -- 166 + 167 + $ jj log 168 + @ n set: introduce Set type main HEAD 1h 169 + ``` 170 + 171 + I have kicked things off by creating a new go module that 172 + adds a `HashSet` data structure. My first changeset 173 + introduces some basic set operations: 174 + 175 + ``` 176 + $ jj log 177 + @ so set: introduce set difference HEAD 178 + ├ sq set: introduce set intersection 179 + ├ mk set: introduce set union 180 + ├ my set: introduce basic set operations 181 + ~ 182 + 183 + $ jj git push -c @ 184 + Changes to push to origin: 185 + Add bookmark push-soqmukrvport to fc06362295bd 186 + ``` 187 + 188 + When submitting a pull request, select "Submit as stacked PRs": 189 + 190 + <figure class="max-w-[550px] m-auto flex flex-col items-center justify-center"> 191 + <a href="static/img/submit_stacked.jpeg"> 192 + <img class="my-1 h-auto max-w-full" src="static/img/submit_stacked.jpeg"> 193 + </a> 194 + <figcaption class="text-center">Submitting Stacked PRs</figcaption> 195 + </figure> 196 + 197 + This submits each change as an individual pull request: 198 + 199 + <figure class="max-w-[550px] m-auto flex flex-col items-center justify-center"> 200 + <a href="static/img/top_of_stack.jpeg"> 201 + <img class="my-1 h-auto max-w-full" src="static/img/top_of_stack.jpeg"> 202 + </a> 203 + <figcaption class="text-center">The "stack" is similar to Gerrit's relation chain</figcaption> 204 + </figure> 205 + 206 + After a while, I receive a couple of review comments, not on 207 + my entire submission, but rather, on each *individual 208 + change*. Additionally, the reviewer is happy with my first 209 + change, and has gone ahead and merged that: 210 + 211 + <div class="flex justify-center items-start gap-2"> 212 + <figure class="w-1/3 m-0 flex flex-col items-center"> 213 + <a href="static/img/basic_merged.jpeg"> 214 + <img class="my-1 w-full h-auto cursor-pointer" src="static/img/basic_merged.jpeg" alt="The first change has been merged"> 215 + </a> 216 + <figcaption class="text-center">The first change has been merged</figcaption> 217 + </figure> 218 + 219 + <figure class="w-1/3 m-0 flex flex-col items-center"> 220 + <a href="static/img/review_union.jpeg"> 221 + <img class="my-1 w-full h-auto cursor-pointer" src="static/img/review_union.jpeg" alt="A review on the set union implementation"> 222 + </a> 223 + <figcaption class="text-center">A review on the set union implementation</figcaption> 224 + </figure> 225 + 226 + <figure class="w-1/3 m-0 flex flex-col items-center"> 227 + <a href="static/img/review_difference.jpeg"> 228 + <img class="my-1 w-full h-auto cursor-pointer" src="static/img/review_difference.jpeg" alt="A review on the set difference implementation"> 229 + </a> 230 + <figcaption class="text-center">A review on the set difference implementation</figcaption> 231 + </figure> 232 + </div> 233 + 234 + Let us address the first review: 235 + 236 + > can you use the new `maps.Copy` api here? 237 + 238 + ``` 239 + $ jj log 240 + @ so set: introduce set difference push-soqmukrvport 241 + ├ sq set: introduce set intersection 242 + ├ mk set: introduce set union 243 + ├ my set: introduce basic set operations 244 + ~ 245 + 246 + # let's edit the implementation of `Union` 247 + $ jj edit mk 248 + 249 + # hack, hack, hack 250 + 251 + $ jj log 252 + Rebased 2 descendant commits onto updated working copy 253 + ├ so set: introduce set difference push-soqmukrvport* 254 + ├ sq set: introduce set intersection 255 + @ mk set: introduce set union 256 + ├ my set: introduce basic set operations 257 + ~ 258 + ``` 259 + 260 + Next, let us address the bug: 261 + 262 + > there is a logic bug here, the condition should be negated. 263 + 264 + ``` 265 + # let's edit the implementation of `Difference` 266 + $ jj edit so 267 + 268 + # hack, hack, hack 269 + ``` 270 + 271 + We are done addressing reviews: 272 + ``` 273 + $ jj git push 274 + Changes to push to origin: 275 + Move sideways bookmark push-soqmukrvport from fc06362295bd to dfe2750f6d40 276 + ``` 277 + 278 + Upon resubmitting the PR for review, Tangled is able to 279 + accurately trace the commit across rewrites, using jujutsu 280 + change-ids, and map it to the corresponding PR: 281 + 282 + <div class="flex justify-center items-start gap-2"> 283 + <figure class="w-1/2 m-0 flex flex-col items-center"> 284 + <a href="static/img/round_2_union.jpeg"> 285 + <img class="my-1 w-full h-auto" src="static/img/round_2_union.jpeg" alt="PR #2 advances to the next round"> 286 + </a> 287 + <figcaption class="text-center">PR #2 advances to the next round</figcaption> 288 + </figure> 289 + 290 + <figure class="w-1/2 m-0 flex flex-col items-center"> 291 + <a href="static/img/round_2_difference.jpeg"> 292 + <img class="my-1 w-full h-auto" src="static/img/round_2_difference.jpeg" alt="PR #4 advances to the next round"> 293 + </a> 294 + <figcaption class="text-center">PR #4 advances to the next round</figcaption> 295 + </figure> 296 + </div> 297 + 298 + Of note here are a few things: 299 + 300 + - The initial submission is still visible under `round #0` 301 + - By resubmitting, the round has simply advanced to `round 302 + #1` 303 + - There is a helpful "interdiff" button to look at the 304 + difference between the two submissions 305 + 306 + The individual diffs are still available, but most 307 + importantly, the reviewer can view the *evolution* of a 308 + change by hitting the interdiff button: 309 + 310 + <div class="flex justify-center items-start gap-2"> 311 + <figure class="w-1/2 m-0 flex flex-col items-center"> 312 + <a href="static/img/diff_1_difference.jpeg"> 313 + <img class="my-1 w-full h-auto" src="static/img/diff_1_difference.jpeg" alt="Diff from round #0"> 314 + </a> 315 + <figcaption class="text-center">Diff from round #0</figcaption> 316 + </figure> 317 + 318 + <figure class="w-1/2 m-0 flex flex-col items-center"> 319 + <a href="static/img/diff_2_difference.jpeg"> 320 + <img class="my-1 w-full h-auto" src="static/img/diff_2_difference.jpeg" alt="Diff from round #1"> 321 + </a> 322 + <figcaption class="text-center">Diff from round #1</figcaption> 323 + </figure> 324 + </div> 325 + 326 + <figure class="max-w-[550px] m-auto flex flex-col items-center justify-center"> 327 + <a href="static/img/interdiff_difference.jpeg"> 328 + <img class="my-1 w-full h-auto" src="static/img/interdiff_difference.jpeg" alt="Interdiff between round #0 and #1"> 329 + </a> 330 + <figcaption class="text-center">Interdiff between round #1 and #0</figcaption> 331 + </figure> 332 + 333 + Indeed, the logic bug has been addressed! 334 + 335 + ## start stacking today 336 + 337 + If you are a jujutsu user, you can enable this flag on more 338 + recent versions of jujutsu: 339 + 340 + ``` 341 + λ jj --version 342 + jj 0.29.0-8c7ca30074767257d75e3842581b61e764d022cf 343 + 344 + # -- in your config.toml file -- 345 + [git] 346 + write-change-id-header = true 347 + ``` 348 + 349 + This feature writes `change-id` headers directly into the 350 + git commit object, and is visible to code forges upon push, 351 + and allows you to stack your PRs on Tangled.

+4

static/icons/bluesky.svg

··· 1 + <svg xmlns="http://www.w3.org/2000/svg" role="img" viewBox="-3 -3 30 30" width="24" height="24"> 2 + <title>Bluesky</title> 3 + <path fill="none" stroke="currentColor" d="M12 10.8c-1.087-2.114-4.046-6.053-6.798-7.995C2.566.944 1.561 1.266.902 1.565.139 1.908 0 3.08 0 3.768c0 .69.378 5.65.624 6.479.815 2.736 3.713 3.66 6.383 3.364.136-.02.275-.039.415-.056-.138.022-.276.04-.415.056-3.912.58-7.387 2.005-2.83 7.078 5.013 5.19 6.87-1.113 7.823-4.308.953 3.195 2.05 9.271 7.733 4.308 4.267-4.308 1.172-6.498-2.74-7.078a8.741 8.741 0 0 1-.415-.056c.14.017.279.036.415.056 2.67.297 5.568-.628 6.383-3.364.246-.828.624-5.79.624-6.478 0-.69-.139-1.861-.902-2.206-.659-.298-1.664-.62-4.3 1.24C16.046 4.748 13.087 8.687 12 10.8Z" stroke-width="2.25"/> 4 + </svg>

+13

static/icons/message-circle.svg

··· 1 + <svg 2 + xmlns="http://www.w3.org/2000/svg" 3 + width="24" 4 + height="24" 5 + viewBox="0 0 24 24" 6 + fill="none" 7 + stroke="currentColor" 8 + stroke-width="2" 9 + stroke-linecap="round" 10 + stroke-linejoin="round" 11 + > 12 + <path d="M2.992 16.342a2 2 0 0 1 .094 1.167l-1.065 3.29a1 1 0 0 0 1.236 1.168l3.413-.998a2 2 0 0 1 1.099.092 10 10 0 1 0-4.777-4.719" /> 13 + </svg>

+15

static/icons/rss.svg

··· 1 + <svg 2 + xmlns="http://www.w3.org/2000/svg" 3 + width="24" 4 + height="24" 5 + viewBox="0 0 24 24" 6 + fill="none" 7 + stroke="currentColor" 8 + stroke-width="2" 9 + stroke-linecap="round" 10 + stroke-linejoin="round" 11 + > 12 + <path d="M4 11a9 9 0 0 1 9 9" /> 13 + <path d="M4 4a16 16 0 0 1 16 16" /> 14 + <circle cx="5" cy="19" r="1" /> 15 + </svg>

static/img/6-months.png