| 1 Aug 2025 |
 emily | for (2), in-memory tools like git revise don't work with pre-commit hooks, and they go against the jj model so they don't work there at all… (pre-push hooks would work here but are even worse in terms of ~shift left~, editor formatting + pre-push is fine but just pre-push is annoying because you get conflicts between commits) | 16:08:09 |
| emily | (and e.g. jj fix works in-memory with arbitrary formatting tools, can fix formatting for an entire stack, and can resolve conflicts caused by reformatting, but it will not work with the Git thing that splices out specific parts of the changed diff) | 16:08:42 |
 Charles | pre commit hooks have always kind of felt like the wrong tool for any job to me | 16:09:00 |
 raitobezarius | I think that's a DX improvement that is worth opening an issue for | 16:09:10 |
| 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 | I am also in agreement with that | 16:09:32 |
| raitobezarius | But for those cases, I just disable the pre-commit hook | 16:09:41 |
| raitobezarius | 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 | 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 | 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 | 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 |
