| 1 Aug 2025 |
emily | alright. I was replying to you talking about the Jujutsu workflow around this. if you had asked about Git I could have given that information too :) | 16:37:54 |
raitobezarius (DECT: 7248) | it's a risk aversion thing | 16:37:54 |
raitobezarius (DECT: 7248) | yeah what i was focusing on is "emilazy cannot format their diffs nicely with jj on lix contributions, so i will try jj and understand what is broken or what could be improved" | 16:38:29 |
raitobezarius (DECT: 7248) | and maybe write docs on how to use jj with lix and stuff | 16:38:35 |
raitobezarius (DECT: 7248) | if it's a one line config or something that can injected in the dev shell | 16:38:48 |
emily | (fwiw: https://github.com/emilio/clang-format-merge/blob/master/clang-format-merge. shipping something of this complexity in the repo will make git mergetool automatically resolve all formatting conflicts) | 16:39:38 |
emily | if it was this simple I already would have solved the issue and not chimed in re: WeetHet's problems
- there are no pre-commit hooks by design
- 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)
- (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
| 16:44:41 |
emily | 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 | 16:45:07 |
emily | or even in 100% upstream Git, git replay which is faster than git rebase because it is in-memory | 16:45:24 |