| 1 Aug 2025 |
 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 |
| raitobezarius | In reply to @charles:computer.surgery
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? No because Lix work involve going back a lot in the past | 16:14:44 |
| raitobezarius | I took care of CVE rebases and stuff, I know that if a formatter was in my way, this could have been one of those moments where this could have exceeded my patience | 16:15:25 |
| raitobezarius | In reply to @emilazy:matrix.org
and the partially-formatted state is worse for them This I truly don't understand | 16:16:02 |
| emily | is this not going to be true when the incremental reformat eventually completes…? | 16:16:06 |
| emily | there is always going to be a flag day | 16:16:14 |
| raitobezarius | In reply to @emilazy:matrix.org
is this not going to be true when the incremental reformat eventually completes…? The window is completely different on an incremental reformat process | 16:16:28 |
