| 12 Sep 2023 |
 infinisil | I think the github UI allows either rebasing or merging | 10:37:29 |
 Alyssa Ross | we don't currently have merge commits everywhere | 10:37:47 |
| infinisil | (by default rebase should be good, but as Profpatsch hints at, merging sometimes makes sense) | 10:37:55 |
| Alyssa Ross | we have a combination of all kinds of merges, based on what each committer thinks is best at the time | 10:38:12 |
 @piegames:matrix.org | What would be needed here IMO is rebase + merge with trivial merge commit. | 10:38:19 |
| Alyssa Ross | yeah we definitely want merge for e.g. staging-next | 10:38:21 |
| Alyssa Ross | what would be the point of the merge commit? | 10:38:35 |
| Alyssa Ross | also, if git can figure out renames on rebasing, I think it should be able to figure them out on merging too/ | 10:38:53 |
| @piegames:matrix.org | In reply to @qyliss:fairydust.space
what would be the point of the merge commit? To associate the individual commits with the PR | 10:39:06 |
| Alyssa Ross | that's not something we do today | 10:39:19 |
| Alyssa Ross | (across the board, at least) | 10:39:31 |
| infinisil | I'm still thinking just ripping the band-aid off with a single commit is probably easiest tbh :)
(and it is what's in the RFC fyi) | 10:39:36 |
| @piegames:matrix.org | hm, didn't know that | 10:39:39 |
| Alyssa Ross | you can look up the PR for a commit using the API / GitHub web anyway | 10:39:53 |
| Alyssa Ross | even if it was "Rebase and Merge"d | 10:39:58 |
| infinisil | Btw I created an RFC 140 milestone: https://github.com/NixOS/nixpkgs/milestone/25 | 10:41:47 |
| infinisil | Was a bit hard to keep track of all the PRs/issues | 10:42:21 |
 profpatsch | staging-next should probably just receive a separate formatting commit | 10:50:38 |
| profpatsch | At least in my mind formatting is deterministic, so no further merge conflicts | 10:51:03 |
| infinisil | (this isn't about formatting though) | 10:51:40 |
| infinisil | * (this isn't about formatting fyi) | 10:51:47 |
| profpatsch | oh, then disregard :) | 10:52:40 |
| profpatsch | I read “the automatic migration” and made an ass out of u & me | 10:53:05 |
| infinisil | Haha nah all good | 10:53:27 |
 teto | I watched the pkgs/by-name nix-con talk . At some point it was mentioned that package sets like haskellPackages / luaPackages were out of scope and I was curious if there was work started regarding those package sets (yet). I have some related questions such as "shall we keep everything in one generated.nix file or explode those in xx/PACKAGE/default.nix" | 11:15:07 |
| teto | one of my main problem is that one package that can't be updated (because wrong src etc) will block the generation of the whole package set. I have started working on a workaround with pytreesitter to replace AST nodes when successful but having per-package files has advantages (but I wonder if the sheer number of new files doesn't make it a no-go anyway) | 11:17:11 |
| infinisil | teto: No concrete plans yet. Quick thoughts regarding single vs multiple files: I think multiple files should be preferred regarding git, it should lead to a smaller repo size and make conflicts less frequent | 11:31:00 |
| infinisil |
Check pkgs/by-name / check (pull_request_target) Successful in 46s
Why does this check seem to take longer now 🙃
| 14:54:20 |
| infinisil | Oh damn, looks like the actions/checkout@v4 is slower: https://github.com/NixOS/nixpkgs/actions/runs/6160467816/job/16717506688?pr=254423 | 14:54:54 |
| infinisil | Or it could be https://github.com/NixOS/nixpkgs/pull/254371 | 14:58:35 |
