| 1 Aug 2025 |
 emily | documenting how to automatically deal with the conflicts is of course a good idea | 16:13:28 |
 raitobezarius (DECT: 7248) | In reply to @emilazy:matrix.org
there have certainly been annoying issues but resolving conflicts if you know the tooling has not been an issue for me. ymmv of course Put in another way:
- If you know what you do, a big reformat commit works
- If you don't, the experience can be miserable
| 16:13:49 |
| emily | but in Nixpkgs a lot of the pain is "old PRs that have not been rebased" etc., whereas the Lix Gerrit already enforces that a commit is based on latest main to submit | 16:13:57 |
| raitobezarius (DECT: 7248) | In practice, we know we are going to have cases of the latter type and we did in the past | 16:14:07 |
| emily | sort of like GitHub vs. Gerrit? :) | 16:14:15 |
| emily | but the other thing is | 16:14:19 |
 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 |
