| 12 Sep 2023 |
 @piegames:matrix.org | Though I'd be interested in some numbers here, like how many pull requests and how many packages are affected by this anyways? How many of these pull requests are younger than three months? | 10:34:49 |
 infinisil | And how many PR's will not have to rebase because of this? I guess the turn-over rate is fairly high, just waiting some weeks probably gets a high percentage | 10:34:56 |
 profpatsch | piegames: I had the same idea during nixcon, but honestly I think it’s totally feasible to require PRs to be rebased on top of master | 10:35:42 |
| profpatsch | Since that parallelizes well | 10:35:48 |
 Alyssa Ross | presumably we could just use "Rebase and Merge" in the UI, as long as git can tell what's going on? | 10:36:13 |
| profpatsch | ofc long feature branches might hate that, but they can merge master back into themselves | 10:36:24 |
| Alyssa Ross | makes the history (and especially bisects) easier too | 10:36:26 |
| @piegames:matrix.org | In reply to @qyliss:fairydust.space
presumably we could just use "Rebase and Merge" in the UI, as long as git can tell what's going on? This would be a deviation from us currently having merge commits everywhere. | 10:37:06 |
| 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 |
