| 1 Aug 2025 |
 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 |
| raitobezarius (DECT: 7248) | We already have some nolint and I remember that we already have troubles with incremental reformatting from time to time but manageable on the scale of it | 18:37:00 |
| raitobezarius (DECT: 7248) | All the nested ternaries lose a lot of their meaning | 18:37:13 |
| raitobezarius (DECT: 7248) | Also, reformatting is not even nolint-preserving | 18:38:14 |
| raitobezarius (DECT: 7248) | So this will cause a lot of manual churn | 18:38:17 |
