| 1 Aug 2025 |
 raitobezarius | But would gladly take issues / solutions for the rest | 16:10:28 |
 emily | because then you can use a pre-commit hook or you can format in your editor (even if your editor is dumb) or you can jj fix and it all works | 16:10:34 |
| raitobezarius | In reply to @emilazy:matrix.org
well my question is what would be unsatisfying about formatting the entire codebase on all branches and enforcing it Diff noise | 16:10:36 |
| emily | the one-time diff noise? or something ongoing? | 16:10:50 |
| raitobezarius | The one time diff noise and the apparently continuous diff noises at every bumps | 16:11:01 |
| raitobezarius | The fact that patches becomes more cumbersome to apply if you are prior to the formatting commit | 16:11:15 |
| raitobezarius | etc. | 16:11:16 |
| emily | I can believe that clang-format changes its output over time but I would be surprised if it changes drastically on a regular basis | 16:11:21 |
| raitobezarius | I think the current team consensus is strongly against "a big formatting commit" | 16:11:31 |
| emily | this is easily fixable in the other direction though | 16:11:41 |
| emily | conflicts caused solely by formatting changes can be mechanically resolved | 16:11:49 |
| emily | not just by jj fix, Git mergetools can handle this | 16:12:00 |
| raitobezarius | In reply to @emilazy:matrix.org
conflicts caused solely by formatting changes can be mechanically resolved Sure but only by people who know enough | 16:12:06 |
| emily | Nixpkgs implemented this with nixfmt | 16:12:10 |
| raitobezarius | It becomes an elevated amount of support load | 16:12:15 |
| raitobezarius | In reply to @emilazy:matrix.org
Nixpkgs implemented this with nixfmt And to me, this is not a success fwiw | 16:12:43 |
| raitobezarius | (All the contrary) | 16:12:48 |
| emily | I'm not really seeing the scenario you're envisioning I think… the format check can tell you how to fix it and Gerrit already insists on fast-forward merges | 16:12:52 |
| 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 |
| emily | and the partially-formatted state is worse for them | 16:14:41 |
