| 23 Sep 2025 |
 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 |
| Wolfgang Walther | exactly | 12:54:43 |
| Vladimír Čunát | So, when are we switching to pijul? 😆 | 12:58:38 |
 Fabián Heredia | Hi, for cmake 4 I want to pull a patch from sourceforge but I can't seem to find an easy way to do that and seems like other maintainers have opted to inline / commit the patch into a file in nikpkgs. wsid?
https://sourceforge.net/p/panotools/libpano13/ci/698e20b4d296c1dbde9d010c3fb8d54050e56ddb/ | 15:03:10 |
| Fabián Heredia | * Hi, for cmake 4 I want to pull a patch from sourceforge but I can't seem to find an easy way to do that and seems like other maintainers have opted to inline / commit the patch into a file in nikpkgs. What should I do?
https://sourceforge.net/p/panotools/libpano13/ci/698e20b4d296c1dbde9d010c3fb8d54050e56ddb/ | 15:03:21 |
| K900 | IMO just vendor it | 15:06:49 |
| K900 | It's three lines who gives a shit | 15:06:52 |
| Vladimír Čunát | Or even substituteInPlace 😄 | 15:39:51 |
