!lymvtcwDJ7ZA9Npq:lix.systems

Lix Development

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

You have reached the beginning of time (for this room).


SenderMessageTime
1 Aug 2025
@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.orgraitobezarius (DECT: 7248)it's a risk aversion thing16:37:54
@raitobezarius:matrix.orgraitobezarius (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:matrix.orgraitobezarius (DECT: 7248)and maybe write docs on how to use jj with lix and stuff16:38:35
@raitobezarius:matrix.orgraitobezarius (DECT: 7248)if 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

Show newer messages


Back to Room ListRoom Version: 10