| 1 Aug 2025 |
 raitobezarius | yes but it only ignore them on git blame | 14:19:37 |
| raitobezarius | not on git rebase, not on git bisect, not on […] | 14:19:46 |
 emily | fwiw I would be so much happier if it was just done outright | 16:03:58 |
| emily | and the conflicts dealt with ~once | 16:04:04 |
| emily | because the partial formatting is inconvenient for My Workflow™ | 16:04:14 |
| emily | (but I suspect others' workflow too, in general partial file formatting is not that great in terms of LSP support etc.) | 16:04:29 |
| raitobezarius | but aren't editors these days able to have project-local configuration? | 16:04:57 |
| emily | Nix is doing (already did?) a treewide format | 16:04:58 |
| emily | or do you mean across stable versions? | 16:05:05 |
| raitobezarius | In reply to @emilazy:matrix.org
or do you mean across stable versions? Yes | 16:05:29 |
 helle (just a stray cat girl) | (cross porting patches can be hilarious at times anyway, but yeah, it would make it more impossible) | 16:05:54 |
| emily | can just format on all branches | 16:05:45 |
| emily | it's not about per-project config, it's about having to do region-based formats rather than whole-file ones etc. | 16:06:11 |
| raitobezarius | In reply to @emilazy:matrix.org
it's not about per-project config, it's about having to do region-based formats rather than whole-file ones etc. That's the job of the pre-commit hook though, no? | 16:06:26 |
| raitobezarius | (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 | 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 | 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 | 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 |
