!lymvtcwDJ7ZA9Npq:lix.systems

Lix Development

423 Members
(Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel.143 Servers

Load older messages


SenderMessageTime
1 Aug 2025
@raitobezarius:matrix.orgraitobezariusMaybe I should forcibly switch myself to Jujutsu to understand what can be achieved16:33:15
@qyriad:katesiria.orgQyriadwe are likely doing that soon16:33:30
@raitobezarius:matrix.orgraitobezariusBut really, this is the best I can offer at this point in time16:33:28
@charles:computer.surgeryCharlesdo iiiiiiit16:33:31
@qyriad:katesiria.orgQyriadpuck uses Jujutsu iwrc16:33:41
@qyriad:katesiria.orgQyriadidk what she does with Lix with it16:33:47
@emilazy:matrix.orgemily I have seen jade_ active in Jujutsu spaces too at least 16:33:55
@helle:tacobelllabs.nethelle (just a stray cat girl)yes, she has been trying to convince me to use it as well16:35:08
@emilazy:matrix.orgemily

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

16:36:02
@charles:computer.surgeryCharlesjj is great. i was hesitant to try it because i felt pretty comfortable with git despite its terrible ux but i regret not trying jj sooner because it's genuinely a huge improvement16:36:08
@raitobezarius:matrix.orgraitobezarius
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

yes but let's be clear again
16:36:35
@raitobezarius:matrix.orgraitobezariusi don't want to make Lix a project that is jj-only16:36:43
@raitobezarius:matrix.orgraitobezariusor usable very much only if you use jj16:36:49
@emilazy:matrix.orgemilysee my second paragraph :(16:36:54
@raitobezarius:matrix.orgraitobezariusok sorry :(16:37:01
@emilazy:matrix.orgemilyI 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 discussion16:37:27
@raitobezarius:matrix.orgraitobezariusbecause 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
@emilazy:matrix.orgemilyalright. 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:matrix.orgraitobezariusit's a risk aversion thing16:37:54
@raitobezarius:matrix.orgraitobezariusyeah 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:matrix.orgraitobezariusand maybe write docs on how to use jj with lix and stuff16:38:35
@raitobezarius:matrix.orgraitobezariusif it's a one line config or something that can injected in the dev shell16:38:48
@emilazy:matrix.orgemily (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
@emilazy:matrix.orgemily

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

16:44:41
@emilazy:matrix.orgemily 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
@emilazy:matrix.orgemily or even in 100% upstream Git, git replay which is faster than git rebase because it is in-memory 16:45:24
@raitobezarius:matrix.orgraitobezariusI don't understand why jj couldn't pass the diff to tools to fix up only certain hunks but ok16:45:55
@raitobezarius:matrix.orgraitobezariusbut understood16:46:32
@qyriad:katesiria.orgQyriad
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:matrix.orgraitobezarius Charles you have testing to do — https://gerrit.lix.systems/c/lix/+/3856 :P 16:46:54

Show newer messages


Back to Room ListRoom Version: 10