Recently discovered this prototype of micro-versioning:

Experimentation plays an essential role in exploratory programming, and programmers apply version control operations when switching the part of the source code back to the past state during experimentation. However, these operations, which we refer to as micro-versioning, are not well supported in current programming environments. We first examined previous studies to clarify the requirements for a micro-versioning tool. We then developed a micro-versioning tool that displays visual cues representing possible micro-versioning operations in a textual code editor. Our tool includes a history model that generates meaningful candidates by combining a regional undo model and tree-structured undo model. The history model uses code executions as a delimiter to segment text edit operations into meaning groups.

https://hiroakimikami.github.io/micro-versioning-tool/index.html

It's nice to see someone exploring this space. Has the teamed looked at

undo-tree

in emacs? It also provides, as the name suggests, a tree-structured undo model. (A-ha! Found the reference in the paper. 😊)

in my normal work I don’t use Undo of work very often. It’s one of the reasons I’ve never liked source code control systems because it’s extremely rare to undo work. Understanding the implications of making changes to code it is really at the crux of the future of computing. Can you make it so that someone can easily understand the implications of what they’re about to change? This is why strong typing It’s so important because it helps the reader understand what could go in a variable. In 99% of the code each variable is going to be used a single way. Users name is never going to become his age. The name is always a string, and it’s only point is to mostly disambiguate a human being from another. One of the problems with these editor Features is that it is not recording why you made the change, so you have this branching tree but you don’t know why you did what you did, so it isn’t that useful.

In Photoshop, I frequently make use of the History panel and Snapshot features, so that I can branch off new variations of an artwork at various points in the past. I could see myself adopting a similarly exploratory programming workflow if my entire toolset were more accommodating of it. Current programming wasn't designed with this freedom in mind, so of course we don't do much of it.

While I agree that one should understand what effect a given change should have, that is not the same as knowing if it is the change one will have wanted to have made after considering it in context, possibly alongside a number of other experimental changes. In general, any theory of programming that assumes we know our destination before we've begun our journey rules out many areas of human endeavor.