| 1 Aug 2025 |
 raitobezarius | I don't understand why jj couldn't pass the diff to tools to fix up only certain hunks but ok | 16:45:55 |
| raitobezarius | but understood | 16:46:32 |
 Qyriad | 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 we use git revise a lot. we have occasionally needed to manually reformat a commit because of it | 16:46:50 |
| raitobezarius | Charles you have testing to do — https://gerrit.lix.systems/c/lix/+/3856 :P | 16:46:54 |
| raitobezarius | ma27 thanks boss | 16:47:55 |
 emily | 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
| 16:50:53 |
| emily | (like the fact that formatting is history-dependent is also why treefmt cannot be used for the C++ part of the codebase, it is just an awkward layering to expose to tooling) | 16:52:40 |
| raitobezarius | I will take all of this home and think about it and do more homework | 16:52:45 |
 Charles | 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 | 16:55:01 |
