| 1 Aug 2025 |
 raitobezarius | ok sorry :( | 16:37:01 |
 emily | I really feel like there is a knowledge gap in how much simple merge tooling that Git supports as well as Jujutsu will resolve all formatting conflict issues automatically and that a small amount of documentation could resolve this, but I also understand that it's effectively not up for discussion | 16:37:27 |
| raitobezarius | because when you drum it too hard, I hear "let's make the experience great for jj users and for git… well doable but enjoy" | 16:37:27 |
| 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 | it's a risk aversion thing | 16:37:54 |
| raitobezarius | 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 | and maybe write docs on how to use jj with lix and stuff | 16:38:35 |
| raitobezarius | 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 |
| 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 |
