| 19 Sep 2025 |
 K900 | Also it probably won't revert cleanly | 15:22:37 |
| K900 | Looking ati t | 15:22:39 |
| K900 | * Looking at it | 15:22:40 |
 emily | eh? it's the last change to cmake | 15:22:51 |
| K900 | WHY DOES UNBOUND REBUILD HASKELL LIKE HELLO | 15:22:54 |
| K900 | As in the revert won't compose cleanly with the PR | 15:23:13 |
| emily | if you revert that commit then the PR applies cleanly. no? | 15:23:55 |
| emily | because that restores the state before the PR got a conflict | 15:24:03 |
| emily | I'm confused | 15:24:08 |
| emily | okay so the patch isn't even in a release branch anyway | 15:24:32 |
| K900 | Yes but then you have an intermediate broken state | 15:24:32 |
| emily | so I do have to actually rebase | 15:24:36 |
| K900 | Oh great | 15:24:38 |
| emily | and that throws away all our CMake builds | 15:24:38 |
| emily | lol | 15:24:40 |
| K900 | I mean | 15:24:43 |
| K900 | I'm also going to merge unbound | 15:24:49 |
| K900 | Probably | 15:24:52 |
| K900 | Which will also do that | 15:24:58 |
| emily | I should probably make sure Darwin still bootstraps with the latest CMake changes that I've been reverting to not throw away all my builds 🫠| 15:26:08 |
| emily | 
Download image.png | 15:32:02 |
| emily | wtf | 15:32:03 |
| emily | CMake branching strategy is nuts | 15:32:05 |
| K900 | Bold of you to assume they have a strategy | 15:33:46 |
| emily | they clearly do | 15:33:54 |
| emily | like | 15:33:56 |
| emily | there is a release-3.2 branch but it's not an actual branch | 15:34:08 |
| emily | instead it's just the latest merge commit with release-3.2 in the message on the release branch | 15:34:17 |
| emily | and its parents correspond to the previous state of that "branch" or whtaever | 15:34:29 |
| emily | * and its parents correspond to the previous state of that "branch" or whatever | 15:34:38 |
