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

In reply to @emilazy:matrix.org
these are also not Jujutsu-specific problems, e.g. any use of git revise or git-branchless or Sapling will also not be getting pre-commit hooks

of course there is no fundamental reason (because you can do it with Git) but

• computing hunk-level diffs is inherently expensive in a snapshot-based VCS like Git or Mercurial or Jujutsu; jj fix is very fast not just because it works in-memory because it specifically avoids having to do any diffing or rebasing of patches even when formatting an entire stack
• the resulting interface to tooling is much more complex and difficult to standardize than providing the repo path and piping through stdin/stdout
• most people working on modern developer tooling do not want to deal with partially-formatted codebases

so I do not find it surprising that there is no existing surface exposed for this