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

In reply to @charles:computer.surgery
i could try to consolidate the conversation into an issue if that would be helpful, assuming the involved parties (raito and emily) are okay with that

In reply to @emilazy:matrix.org
(I just think it is only worth having an issue if there is a possibility that the information it contains could result in a changed decision)