| 1 Aug 2025 |
raitobezarius (DECT: 7248) | ma27 thanks boss | 16:47:55 |
emily | of course there is no fundamental reason (because you can do it with Git) but
- computing hunk-level diffs is inherently expensive in a snapshot-based VCS like Git or Mercurial or Jujutsu;
jj fix is very fast not just because it works in-memory because it specifically avoids having to do any diffing or rebasing of patches even when formatting an entire stack
- the resulting interface to tooling is much more complex and difficult to standardize than providing the repo path and piping through stdin/stdout
- most people working on modern developer tooling do not want to deal with partially-formatted codebases
so I do not find it surprising that there is no existing surface exposed for this
| 16:50:53 |
emily | (like the fact that formatting is history-dependent is also why treefmt cannot be used for the C++ part of the codebase, it is just an awkward layering to expose to tooling) | 16:52:40 |
raitobezarius (DECT: 7248) | I will take all of this home and think about it and do more homework | 16:52:45 |
Charles | i could try to consolidate the conversation into an issue if that would be helpful, assuming the involved parties (raito and emily) are okay with that | 16:55:01 |
Charles | probably just copy+pasting the relevant/substantive bits directly from matrix lol | 16:55:22 |
Sergei Zimmerman (xokdvium) | FWIW cppnix codebase has been reformatted. | 16:56:02 |
emily | if you'd like to see such an issue I'll see if I have energy to put my thoughts in more organized form in a little while, if you'd like to save yourself the trouble | 16:57:14 |
emily | (I just think it is only worth having an issue if there is a possibility that the information it contains could result in a changed decision) | 16:57:31 |
Charles | i mean it seems like the chance is nonzero at least | 16:58:39 |
raitobezarius (DECT: 7248) | In reply to @charles:computer.surgery i could try to consolidate the conversation into an issue if that would be helpful, assuming the involved parties (raito and emily) are okay with that yep, would be good | 16:59:33 |
raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org (I just think it is only worth having an issue if there is a possibility that the information it contains could result in a changed decision) I won't lie, I think the bar is very high for such a decision to happen | 16:59:55 |
raitobezarius (DECT: 7248) | So I don't want to be deceptive and snipe you | 17:00:00 |
raitobezarius (DECT: 7248) | I'm open to approach it with an open mind and look at it for what it is | 17:00:08 |
emily | was that assessment made with or without knowledge of the existence of git mergetool? 😅 | 17:00:42 |
raitobezarius (DECT: 7248) | It was done with the knowlege of git mergetool | 17:00:52 |
emily | I am really confused as to the conflict issues that are being envisioned then. but ok. I will leave it be | 17:12:20 |
emily | I put up https://git.lix.systems/lix-project/lix/issues/948 | 17:51:03 |
emily | to have the discussion recorded | 17:51:09 |
emily | https://gerrit.lix.systems/c/lix/+/3858 could probably use an urgent +2 btw | 17:51:14 |
Qyriad | done | 17:53:04 |
emily | ty | 17:53:19 |
emily | sorry for the regression | 17:53:22 |
Qyriad | we approved it, so we bear that responsibility too | 17:53:40 |
raitobezarius (DECT: 7248) | we should rerun CI manually on d5cfc6f19c and f077a6f36e | 18:09:44 |
raitobezarius (DECT: 7248) | taking care of it | 18:10:14 |
raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org I am really confused as to the conflict issues that are being envisioned then. but ok. I will leave it be I double checked again and one reason that I see is that clang-format output is bad in certain (common in the Lix codebase) corner cases | 18:35:29 |
raitobezarius (DECT: 7248) | And this is reason enough to proceed blindly with a full reformat | 18:35:36 |
raitobezarius (DECT: 7248) | * And this is reason enough to not proceed blindly with a full reformat to me | 18:35:41 |
raitobezarius (DECT: 7248) | If being broken on multiple lines with their literals cut in half, call being laid out on multiple lines breaking the logical manual grouping | 18:36:08 |