| 1 Aug 2025 |
 emily | well I should clarify: pre-commit hooks that automatically fix things up are not inherently hateful to me, but anything that stops me making a commit is awful workflow-wise | 16:09:13 |
| emily | I make a lot of commits in rough draft/often broken state and then clean them up extensively before publication | 16:09:24 |
 raitobezarius (DECT: 7248) | I am also in agreement with that | 16:09:32 |
| raitobezarius (DECT: 7248) | But for those cases, I just disable the pre-commit hook | 16:09:41 |
| raitobezarius (DECT: 7248) | And do my work | 16:09:45 |
| emily | git commit being a blocking/fallible operation is unpleasant, with Jujutsu the workflow is even more fluid so the idea of it would be even worse :p | 16:09:47 |
| raitobezarius (DECT: 7248) | I don't think there's a good solution to satisfy everyone | 16:09:55 |
| emily | and then you have to fix up commit 1, and then commit 2 gets conflicts, etc. | 16:10:02 |
| raitobezarius (DECT: 7248) | So I'm more inclined to pursue solutions that does not get in the way of the existing contributing force to be clear | 16:10:12 |
| emily | well my question is what would be unsatisfying about formatting the entire codebase on all branches and enforcing it | 16:10:20 |
| raitobezarius (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | The one time diff noise and the apparently continuous diff noises at every bumps | 16:11:01 |
| raitobezarius (DECT: 7248) | The fact that patches becomes more cumbersome to apply if you are prior to the formatting commit | 16:11:15 |
| raitobezarius (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | It becomes an elevated amount of support load | 16:12:15 |
| raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org
Nixpkgs implemented this with nixfmt And to me, this is not a success fwiw | 16:12:43 |
| raitobezarius (DECT: 7248) | (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 (DECT: 7248) | 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 |
