| 1 Aug 2025 |
 raitobezarius | The amount of time I lost due to the big reformat of Nixpkgs is nontrivial | 16:12:57 |
 emily | there have certainly been annoying issues but resolving conflicts if you know the tooling has not been an issue for me. ymmv of course | 16:13:21 |
| emily | documenting how to automatically deal with the conflicts is of course a good idea | 16:13:28 |
| raitobezarius | In reply to @emilazy:matrix.org
there have certainly been annoying issues but resolving conflicts if you know the tooling has not been an issue for me. ymmv of course Put in another way:
- If you know what you do, a big reformat commit works
- If you don't, the experience can be miserable
| 16:13:49 |
| emily | but in Nixpkgs a lot of the pain is "old PRs that have not been rebased" etc., whereas the Lix Gerrit already enforces that a commit is based on latest main to submit | 16:13:57 |
| raitobezarius | In practice, we know we are going to have cases of the latter type and we did in the past | 16:14:07 |
| emily | sort of like GitHub vs. Gerrit? :) | 16:14:15 |
| emily | but the other thing is | 16:14:19 |
 Charles | i think it's more like "if you don't, the experience can be miserable, IF you need to rebase changes across the formatting commit" which seems like it would be pretty rare if you formatted all branches, no? | 16:14:22 |
| emily | there are a finite and relatively small number of patches in flight right now | 16:14:26 |
| emily | there are always new people creating new patches from scratch | 16:14:32 |
