| 1 Aug 2025 |
 raitobezarius | (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 | 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 | 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 | 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 | (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 | (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 | In reply to @charles:computer.surgery
for backporting or forward-porting? for performance tracking, root cause analysis, etc. | 16:24:52 |
| raitobezarius | We go back, we cherry pick things, we revert things and so on and so forth | 16:25:00 |
| raitobezarius | 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 | 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 | 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 | (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 |
| emily | if the decision is as overdetermined as it sounds I probably won't have energy to open a Forgejo issue sadly | 16:27:23 |
| emily | I will probably just keep creating non-formatted diffs, since… well, CI is happy with it | 16:27:34 |
| emily | (the algorithm is simply: to rebase a commit that takes state A to state B across formatting, format A and B to produce A' and B' and diff B' against A'. Git mergetools or jj fix or whatever only enter the picture in how you make this happen; the algorithm itself works 100% reliably to produce the commit you would have produced if the change was written post-format) | 16:29:20 |
| raitobezarius |
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 :(
It's totally is and I'm sorry for that, I don't consider formatting discussions table stakes compared to other high profiles debates we may have here, especially given that it will impact first and foremost the people who are the most active sending patches & working on Lix (and I realize that this may discourage people who are not sending patches or work on Lix, but I don't know how many of them exist and if patches would happen if the codebase is reformatted that way), so it's a bit of I prioritize the regularity that I know right now | 16:30:18 |
| raitobezarius | In reply to @emilazy:matrix.org
I will probably just keep creating non-formatted diffs, since… well, CI is happy with it and I'm totally happy with that as well | 16:30:53 |
| raitobezarius | In reply to @emilazy:matrix.org
(the algorithm is simply: to rebase a commit that takes state A to state B across formatting, format A and B to produce A' and B' and diff B' against A'. Git mergetools or jj fix or whatever only enter the picture in how you make this happen; the algorithm itself works 100% reliably to produce the commit you would have produced if the change was written post-format) Don't get me wrong, I totally believe you that this is achievable | 16:31:08 |
| raitobezarius | Formatting is, to me, more than a technical discussion so I don't want you to lose time over something that I believe will disappoint more the participants than the ultimate achieved outcome | 16:31:55 |
| emily | (I find it discouraging that I am having to manually do code formatting tasks (albeit likely formatting-standard-noncompliant ones) because I cannot reasonably use the tooling fwiw) | 16:32:02 |
| raitobezarius | Obviously, this can be revisited in the future | 16:32:04 |
| emily | (I do know there are other Lix contributors using Jujutsu so I wonder what the workflow being used to deal with this is, but I suspect it involves editor hooks) | 16:32:56 |
