| 23 Sep 2025 |
 Wolfgang Walther | Will you or shall I? | 12:28:59 |
 K900 | If you have the time | 12:29:25 |
| K900 | I am still pretty sick and busy with $work | 12:29:36 |
| Wolfgang Walther | Ok, I will look at it. | 12:29:51 |
| Wolfgang Walther | Turns out this update is already on staging as https://github.com/NixOS/nixpkgs/commit/60eb2b5686aa3a4d7f9a8f11d7757d259be9f34e. So no need to re-apply. I can't really wrap my head around how the revert was able to propagate back to staging without breaking this (by reverting back the version number), but it seems everything is alright. | 12:39:41 |
| Wolfgang Walther | (it's even on staging-next, so I assume there was a conflict to resolve when merging master to staging-next earlier?) | 12:40:19 |
| Wolfgang Walther | Which also means.. that I'm not sure whether the revert actually stopped the mass rebuild - or whether that was caused by resolving the merge conflicts? | 12:41:44 |
 Vladimír Čunát | 🤔 I think default merging will merge two same changes without conflict? | 12:41:52 |
| Vladimír Čunát | (i.e. if both sides make the same change, it just passes) | 12:42:14 |
| Vladimír Čunát | * (i.e. if both sides of the 3-way diff make the same change, it just passes) | 12:42:25 |
| Vladimír Čunát | Though I believe there's not a 100% consensus whether that's a good thing to do. | 12:42:59 |
| Wolfgang Walther | Yeah, but:
- staging changes to 1.14.0 -> 1.15.1, this is now in staging-next
- master changes the same.
- master is merged into staging-next, but now has a conflict in the fetcher.
- this conflict is resolved when manually merging. (probably in a wrong way, if that caused a mass rebuild - the right conflict resolution should have just kept what was on staging-next!)
- we revert on master.
- the revert is merged cleanly into staging-next... the diff shows "1.15.1 -> 1.14.0".
- But the file still has "1.15.1" in it.
How did the revert apply and show a diff - but not make a change?
| 12:44:38 |
| Wolfgang Walther | It seems that the merges from master->staging-next->staging after the revert didn't actually apply the revert. At least the diff for these merges doesn't show any changes to that file. | 12:46:43 |
| Vladimír Čunát | Ah, you reverted too fast. | 12:49:18 |
| Vladimír Čunát | So staging-next never knew this merge+revert. | 12:49:36 |
| Vladimír Čunát | i.e. the merge base (for master->staging-next) always seemed like master didn't change anything and staging-next updated it. | 12:50:29 |
| Wolfgang Walther | Ah, that was a misunderstanding on my part, then. | 12:50:40 |
| Wolfgang Walther | I thought this was already in staging-next. | 12:50:47 |
| Wolfgang Walther | But it was what caused the merge conflict and never made it there. | 12:50:55 |
| Wolfgang Walther | After the revert, the state was clean again. | 12:51:00 |
| Wolfgang Walther | (there was never a manual merge) | 12:51:07 |
| Vladimír Čunát | It is in staging-next now, but there was no auto-merge on the state between merging the PR and reverting it. | 12:51:58 |
| Vladimír Čunát | * It is in staging-next now, but there was no merge on the state between merging the PR and reverting it. | 12:52:10 |
| Wolfgang Walther | yes. | 12:52:15 |
| Wolfgang Walther | It only came in as merge+revert = no-op. I see. | 12:52:22 |
| K900 | Yeah | 12:52:35 |
| Wolfgang Walther | In any case, the update is already there, so nothing to do for me :D | 12:52:54 |
| Vladimír Čunát | Rarely you run into such "problems" resulting from the dumbness of 3-way merging. | 12:53:05 |
| Vladimír Čunát | If the auto-merge timing was different, it would resolve differently. | 12:53:21 |
| Vladimír Čunát | Or "luckily" it wouldn't merge cleanly because of the fetcher rewrite. | 12:54:31 |
