In reply to @emilazy:matrix.org
I will probably just keep creating non-formatted diffs, since… well, CI is happy with it

In reply to @emilazy:matrix.org
(the algorithm is simply: to rebase a commit that takes state A to state B across formatting, format A and B to produce A' and B' and diff B' against A'. Git mergetools or jj fix or whatever only enter the picture in how you make this happen; the algorithm itself works 100% reliably to produce the commit you would have produced if the change was written post-format)

as long as you have a formatting tool that can work in-memory on entire files (treefmt with the right configuration achieves this, clang-format can do it, nixfmt can do it, etc.) you can jj fix -s X on any X that has formatting-related conflicts (e.g., from a rebase or merge or revert) and the remaining conflicts in X and its children will be exactly the non-formatting ones. (jj fix -s X is also the tool that fixes formatting in X and its children in the absence of any conflicts)

I wouldn't call this a Jujutsu perk though because as I said the exact same results can be achieved with Git and insofar as it is more awkward to do so it is only the usual Jujutsu–Git delta of awkwardness

In reply to @emilazy:matrix.org

as long as you have a formatting tool that can work in-memory on entire files (treefmt with the right configuration achieves this, clang-format can do it, nixfmt can do it, etc.) you can jj fix -s X on any X that has formatting-related conflicts (e.g., from a rebase or merge or revert) and the remaining conflicts in X and its children will be exactly the non-formatting ones. (jj fix -s X is also the tool that fixes formatting in X and its children in the absence of any conflicts)

I wouldn't call this a Jujutsu perk though because as I said the exact same results can be achieved with Git and insofar as it is more awkward to do so it is only the usual Jujutsu–Git delta of awkwardness

if it was this simple I already would have solved the issue and not chimed in re: WeetHet's problems

1. there are no pre-commit hooks by design
2. the current tooling to run fixers like formatters across commits, and to resolve formatting-related conflicts, is great but oriented around in-memory tools (whereas the partial Git stuff currently used can rely on doing a full slow checkout on each commit of a stack and computing the diff). (the partial reformatting regime means that this makes things harder for me even if I ignore formatting, because I can rebase over some code someone touched that then got reformatted and have conflicts that cannot be trivially resolved in one command due to the current scheme not formatting whole files)
3. (I am often making changes with dumb editors and doing things in general weird ways so even if I set up editor hooks I would still want to be able to reliably check and fix a whole stack for formatting, especially since I am frequently squashing things from one commit to another and splitting commits etc.)

I think the options are using a colocated repository so the Git reformatter thing can work (and hoping that it works with detached HEAD) and rigorously ensuring I always have it get run by editors etc., or writing a manual slow script that checks out commits in sequence to fix them up and cannot easily be used to resolve conflicts unless I put in even more work