| 1 Aug 2025 |
 raitobezarius (DECT: 7248) | (or git-clang-format) | 16:06:36 |
 Charles | lots of people configure their editor to format files on save, which is super useful | 16:07:02 |
 emily | yes if
- you are okay having no formatting while you work on commits, which can be very annoying
- you use tooling that works with pre-commit hooks
- pre-commit hooks do not make you fly into a rage
| 16:07:08 |
| raitobezarius (DECT: 7248) | I feel like there's three schools of thoughts:
- no formatting enforced
- partial formatting
- full formatting
| 16:07:11 |
| emily | I'm good with (1) but not (2) or (3) | 16:07:14 |
| raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org
I'm good with (1) but not (2) or (3) Can you explain why (3) applies | 16:07:58 |
| 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 (DECT: 7248) | 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 (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 |
