Why is it so hard to see code from 5 minutes ago?

> I'll walk through some reasons why version control does not save the day here. While a developer is making changes to code, they may not realize that they want some intermediate version from a few minutes ago until they are well into making the change and become stuck. We saw this repeatedly in our studies. This introduces a problem of premature commitment3, which forces the developer to decide to save an intermediate version (or not to save it) before they have the information needed to make the decision (whether they will need it or not). Unless you commit code to your git repository every few minutes, working or not working, then version control won't help you here.

Presuming DVCS here; if you’re still on a centralized VCS this is surely Not Good:

So, you need an editor utility that automatically commits every save (and possibly autosaves and commiys every completed undo-list item)on a special temporary branch that gets deleted when you do a real commit, and if you go back to prior state on that branch it automatically does the same but starts a new temporary branch with the next item, deleting the whole temp tree on a real commit. Or maybe leave the temp branches around until manually cleaned up, but provide a UI to do that in an all-at-once sweep.

The obvious challenges seem to be managing temp-branch vs. “real” current branch state in a way that doesn't mess up or get messed up by other tools interacting with the repo (including ha sling things like pulls and other inbound changes to your “real” active branch), and generating non-noise automated commit messages. Advantages would be all the tools you have for VCS history can then be deployed to your edit history without any additional friction.

My short term memory is much reduced compared to my younger self. Consequently, I work in ways which allow me to reduce cognitive load and still accomplish the task. FP is a godsend for me, even if I just adopt some of its principles.

You can stage/unstage selected ranges with vscode+git, useful but not a tree. Has bad behavior if you choose some portion of a range, or if the unstage will stomp on some other inflight change

I’ve never heard someone talk about this before, I’m sure developing good development techniques and relying on editor auto complete would alleviate most of those listed issues.

In my 30 years of professional programming, and even with my admittedly declining short term memory, I have never felt lost without access to versions of code from 5-15 minutes ago.

Not to be harsh, but I really think that this indicates some fundamental approach issue rather than a tooling problem.

If it cannot be written on paper (or tablet note with pen) as rough pseudocode... or even drawing boxes and arrows for the visually-inclined, then the problem is not understood. Take what is understood and codify it, pushing the complexity and the unknowns to the edges. At least that reduces the complexity.

One aid I do lean on heavily though is a REPL. Load the code and do some interactive work with it. Inspect the data, test some transformations, and then write code to do what works. That's my current approach to situations that I cannot immediately and accurately write in one pass.