| 1 Aug 2025 |
 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 |
| raitobezarius | 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 | 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 | 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 | 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 | So I don't want to be deceptive and snipe you | 17:00:00 |
| raitobezarius | 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 | 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 | we should rerun CI manually on d5cfc6f19c and f077a6f36e | 18:09:44 |
