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.