| 1 Aug 2025 |
 Charles | i think it's more like "if you don't, the experience can be miserable, IF you need to rebase changes across the formatting commit" which seems like it would be pretty rare if you formatted all branches, no? | 16:14:22 |
 emily | there are a finite and relatively small number of patches in flight right now | 16:14:26 |
| emily | there are always new people creating new patches from scratch | 16:14:32 |
| emily | and the partially-formatted state is worse for them | 16:14:41 |
 raitobezarius (DECT: 7248) | In reply to @charles:computer.surgery
i think it's more like "if you don't, the experience can be miserable, IF you need to rebase changes across the formatting commit" which seems like it would be pretty rare if you formatted all branches, no? No because Lix work involve going back a lot in the past | 16:14:44 |
| raitobezarius (DECT: 7248) | I took care of CVE rebases and stuff, I know that if a formatter was in my way, this could have been one of those moments where this could have exceeded my patience | 16:15:25 |
| raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org
and the partially-formatted state is worse for them This I truly don't understand | 16:16:02 |
| emily | is this not going to be true when the incremental reformat eventually completes…? | 16:16:06 |
| emily | there is always going to be a flag day | 16:16:14 |
| raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org
is this not going to be true when the incremental reformat eventually completes…? The window is completely different on an incremental reformat process | 16:16:28 |
| raitobezarius (DECT: 7248) | (also because I literally had to deal with very few issues reformatting to very old versions) | 16:16:49 |
| emily | this started with WeetHet giving an example (and it's also bad enough for my workflow that I'm just pushing formatting-noncompliant diffs right now), it may be that for WeetHet the solution is simple as finding the right editor toggle, but that's still not zero pain either | 16:17:16 |
| emily | right I mean I agree that formatting on only one branch would be bad | 16:17:36 |
| emily | but I don't see any reason why you'd do that | 16:17:42 |
| raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org
this started with WeetHet giving an example (and it's also bad enough for my workflow that I'm just pushing formatting-noncompliant diffs right now), it may be that for WeetHet the solution is simple as finding the right editor toggle, but that's still not zero pain either I understand the pains and I'm willing to see how we can better document help, even check in the files to do per-project configuration automatically for you | 16:18:06 |
| raitobezarius (DECT: 7248) | I do not think that a big reformat commit is at the agenda and will not be unless there's a very compelling reason to do so | 16:18:23 |
| emily | I am pretty confident that there is no fix you can do with the current scheme that will be tolerable for my workflow. (but most people's problems are probably not my workflow's problems) | 16:18:47 |
| raitobezarius (DECT: 7248) | I understand that and I am sorry we cannot do better | 16:19:05 |
| emily | (it is frustrating that hypothetical problems without enough detail provided to explain why they would cause issues that cannot trivially be solved are prioritized over real-world problems people are having now…) | 16:20:29 |
| Charles | for backporting or forward-porting? | 16:21:34 |
| raitobezarius (DECT: 7248) | (If I had energy to sit down, review the notes we had on this, provide them, go into it, come to the conclusion we cannot do it for valid reasons and spent that energy, I think other priorities that I deem more important would be abandoned, so I'm sorry I'm pushing back on this a bit because we know what tradeoffs we made. Another thing important to me is that these apparently simple decisions are taken by people with stakes / responsibilities in the project otherwise I feel like it's the in-charge maintainers who have to carry them and it's a bit unfair if they are not comfortable with them.) | 16:23:46 |
| raitobezarius (DECT: 7248) | (but if I were only in charge of DX / formatting, I'd do it with pleasure but I'm really too strained right now) | 16:24:22 |
| raitobezarius (DECT: 7248) | In reply to @charles:computer.surgery
for backporting or forward-porting? for performance tracking, root cause analysis, etc. | 16:24:52 |
| raitobezarius (DECT: 7248) | We go back, we cherry pick things, we revert things and so on and so forth | 16:25:00 |
| raitobezarius (DECT: 7248) | It's not only for actually applying patches, it's also part of our development cycle | 16:25:10 |
 K900 | just filter-branch it | 16:25:49 |
| raitobezarius (DECT: 7248) | When we go back 14 years ago, sometimes, the patches are trivial enough and we can rewrite them by hand, but we would prefer stability | 16:25:52 |
| raitobezarius (DECT: 7248) | In reply to @raitobezarius:matrix.org
(If I had energy to sit down, review the notes we had on this, provide them, go into it, come to the conclusion we cannot do it for valid reasons and spent that energy, I think other priorities that I deem more important would be abandoned, so I'm sorry I'm pushing back on this a bit because we know what tradeoffs we made. Another thing important to me is that these apparently simple decisions are taken by people with stakes / responsibilities in the project otherwise I feel like it's the in-charge maintainers who have to carry them and it's a bit unfair if they are not comfortable with them.) Also, in general: I think these discussions are better suited in a medium like Forgejo issues, because I'm like the only core team member chiming in there and it's also unfair that no one else will come and provide answers | 16:26:43 |
| raitobezarius (DECT: 7248) | (hence why I push to the issues) | 16:26:55 |
| emily | I understand limited time to deal with such decisions but I feel like "we can spend time talking about how to patch your/others' problems with the current workflow but not spend equivalent time explaining our problems with the proposed workflow" is somewhat imbalanced :(
again, any problem caused by a patch going forward across a pre-format state to a post-format one can be solved 100% automatically with one single command, in all cases. (as in, any remaining conflicts are guaranteed to be for non-reformatting reasons.) so it can never get more than one command in the way of a revert or cherry-pick from pre-reformatting. I believe the cost of the current workflow is >one command for at least me and likely others | 16:26:57 |
