In reply to @raitobezarius:matrix.org
(If I had energy to sit down, review the notes we had on this, provide them, go into it, come to the conclusion we cannot do it for valid reasons and spent that energy, I think other priorities that I deem more important would be abandoned, so I'm sorry I'm pushing back on this a bit because we know what tradeoffs we made. Another thing important to me is that these apparently simple decisions are taken by people with stakes / responsibilities in the project otherwise I feel like it's the in-charge maintainers who have to carry them and it's a bit unfair if they are not comfortable with them.)

I understand limited time to deal with such decisions but I feel like "we can spend time talking about how to patch your/others' problems with the current workflow but not spend equivalent time explaining our problems with the proposed workflow" is somewhat imbalanced :(

It's totally is and I'm sorry for that, I don't consider formatting discussions table stakes compared to other high profiles debates we may have here, especially given that it will impact first and foremost the people who are the most active sending patches & working on Lix (and I realize that this may discourage people who are not sending patches or work on Lix, but I don't know how many of them exist and if patches would happen if the codebase is reformatted that way), so it's a bit of I prioritize the regularity that I know right now

In reply to @emilazy:matrix.org
I will probably just keep creating non-formatted diffs, since… well, CI is happy with it

In reply to @emilazy:matrix.org
(the algorithm is simply: to rebase a commit that takes state A to state B across formatting, format A and B to produce A' and B' and diff B' against A'. Git mergetools or jj fix or whatever only enter the picture in how you make this happen; the algorithm itself works 100% reliably to produce the commit you would have produced if the change was written post-format)

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