A couple of days ago I noticed a bug that's been in all my apps since I started programming with LÖVE at the start of 2022. Start searching for text, type nothing into the pattern to search for, then find again repeatedly. Crash. Caused by misusing a Unicode library, even though this bug needs no special chars to trigger. Now I've pulled the bugfix into 54 forks 😮‍💨

That's a frequent criticism I hear when I try to convince colleagues to go for re-editable (rather then re-usable) software. I believe this should be automatable, though perhaps require adapted tooling. The hard part is keeping track of forks as they are made. For a single person this just requires adopting some discipline, but for groups it probably requires some mechanism to register forks in some central place. Any thoughts on this? I guess you are in the "individual" category for now.

... The hard part is keeping track of forks as they are made. ...

FWIW: I don't know of a solution for this kind of problem, but, things like NiCaD make me believe that steps towards solving this kind of thing are possible. I find

git

to be a bother when I'm re-editing code, hacking and exploring problem spaces. I don't know before-hand where I'm going nor what I'm going to do next. I need a tool that auto-saves a tree of branches of my explorations without needing me to stop and stroke git, trying to predict when I will want to save a change vs. backtracking, trying something else, and, cleaning up after myself. I need

emacs

to create and commit a new git branch every time I do a save.

@Konrad Hinsen Yeah, this is the key question to the whole approach, isn't it? I have a few responses: • The conventional approach is to trust a third party to make sure changes are applied everywhere they should be. That isn't going well. Software is full of regressions. • The conventional approach is to bundle a bunch of unrelated code higgledy-piggledy as features in shared codebases. That isn't going well. It remains challenging to ensure a bug is fixed in every applicable combination of features. • Paradoxically the best way to avoid the drawbacks of reeditable software is to avoid editing it too much. The goal of my prolific spawning of forks is to keep each fork simple and stable as far as possible. The root of my tree, for example, only gets modified for bugfixes these days. And bugfixes are growing more rare, particularly in the subtree since my recent big rewrite. Though I'm still maintaining previous subtrees, which brings me to.. • The conventional approach is to let old configurations go stale. Once you've written a paper you don't bother updating its code. You can do that just as well with this approach, just with greater transparency, jettisoning outdated configurations to obviously outdated forks. I've been taking on more pain than I need to, just to get a sense of problems beyond an individual scale. • I think we can build tools for reducing the pain of fixing merge conflicts repeatedly in a bunch of forks. Git can remember and replay merge conflicts, but currently only in a single fork. I track new version control programs like Pijul and jj because they may help with this use case by starting from more principled foundations. (It's unclear so far if they do.) So it's important not to compare the fully mature state of conventional software with the embryo of a new approach. (Has anyone experimented with training AI to fix merge conflicts? Delegate the boring parts of building, not the fun parts.) • I do have some tools for speeding things up. (My tool for keeping track of forks is just a flat file containing a topologically sorted list of directories to iterate through. Each directory keeps track of its upstream in git config.) It takes me 1-2 hours to pull a patch through all my forks. Where the tools are lacking, I prioritize the quality of the result over some periodic tedium. Bottomline for now: the conventional way to make software is better in one way: it lets us all sit around, stewing in incompetence, pointing fingers at each other, safe in the knowledge that nobody will blame any single one of us directly for most problems. The conventional way is worse in one way: there's no good way for the individual who truly cares about the quality of their work to carve out an area to cultivate. In my approach they can start managing their own forks, do the tedious work needed to stamp out bugs once and for all, and to avoid regressions.

@guitarvydas I use git-sync for automatic snapshots of explorative work, and also for my notes. You could easily tell Emacs to do it for every save. You can also use Git hooks for committing and pushing automatically when a file changes in the repository, that's what I do for my password collection (via Password Store). None of this is perfect, but I find these solutions good enough for me.

I'd say the mainstream is less appealing to me for the reasons I gave 😄 Once I understand the consequences to quality of that approach, I can't let lack of tooling keep me from aiming higher.

Indeed.... Maybe it's more like: the mainstream is always attractive to mainstream-type people 😉