| 1 Aug 2025 |
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 |
raitobezarius | (also because I literally had to deal with very few issues reformatting to very old versions) | 16:16:49 |
emily | this started with WeetHet giving an example (and it's also bad enough for my workflow that I'm just pushing formatting-noncompliant diffs right now), it may be that for WeetHet the solution is simple as finding the right editor toggle, but that's still not zero pain either | 16:17:16 |
emily | right I mean I agree that formatting on only one branch would be bad | 16:17:36 |
emily | but I don't see any reason why you'd do that | 16:17:42 |