34 ms·

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

• lazyjeff 6y ago
  This is awesome, I would use it. Maybe make it a visual studio code plugin?
  • tomjuggler 6y ago
    I came here to say this also.
• blibble 6y ago
  jetbrains IDEs have a local history feature that seems to do this
  • deleted 6y ago
    [deleted]
  • azhenley 6y ago
    When I looked, it had the same problem that Dropbox has with this: a textual listing with only timestamps. I need semantic info! Show me the differences. Don't make me choose from this arbitrary list. I want to scan through the versions very, very quickly.
    • avisser 6y ago
      Not sure what you're looking at, but IntelliJ 2020.3 gives me a list w/ timestamps in 1/3 of the modal, then a diff viewer in the other 2/3. I can down-arrow through the versions and the diff updates.
      • azhenley 6y ago
        Fantastic, downloading the latest version now!
        • Semaphor 6y ago
          That has been in for quite some time. I don’t remember since when, but at least in the 2019 version.
      • lights0123 6y ago
        That's the way it's been for years.
  • dopidop 6y ago
    Yeah and it’s actually decent. That being said I don’t mind committing often. If I have a slew of small commits I squash them. Since I will need to commit at some point, I rather do it incrementally.
    • BurningFrog 6y ago
      Committing removes the diff view in PyCharm, and I can't lose that. By "diff view" I mean I can see all the changes I've done from the main branch.
      • jlund-molfese 6y ago
        Personally, when I'm ready to submit a pull request, I usually do a soft reset to the point where I branched off from, then redo my commits and force push to the branch, for exactly that reason. I can't remember exactly which lines I've changed over the past few days unless I see all the diffs together.
        • BurningFrog 6y ago
          Interesting idea... I suppose I can stash my current code, reset to where I started somehow, and then unstash. I've also toyed with the idea of having two repos on my disk.
  • winwhiz 6y ago
    Came here to say this. It is a really old feature.
    • topspin 6y ago
      It is, and yes I've found it useful. However, the idea of a slider that you can just yank around sounds really appealing.
  • easton_s 6y ago
    I use view local history of selected so I can blame myself and view git history of selected to I secretly seethe at some one who left the company 3 years ago.
  • rurp 6y ago
    Yep, it's quite a handy feature at times. I don't use it a ton, but it is very helpful when I want it. One very nice aspect is that you can scope it to a specific section within a file (the same can be done with git history as well).
• treve 6y ago
  Vim has time-based undo which is great, but I always forget about it and need to look up how to use it the few times that I want it. Having a slider/timeline does sound like an excellent idea. Also just being able to non-destructively go back to a previous state and have a peak without changing the files I'm working on right now would would really well for me I think. Of course git is an answer to this, but I don't want to think about making a checkpoint.
• Asooka 6y ago
  In Vim you can achieve something quite similar with gundo plugin. Vim tracks all your changes in a tree by default and you can also use the "earlier" and "later" commands with a time delta to go back and forward a specified amount of time. So in Vim, to see the state of the file 5 minutes ago, you type ":earlier 5m" . Gundo is a visualisation on top of the builtin undo. I'm sure Emacs has something similar and probably more powerful, but I'm not familiar with it. I'm not aware of other editors having tree undo.
  • stephen272 6y ago
    Emacs does indeed have a plugin for this called "undo-tree". I think it is missing the ability to specify a time to go back by, but you can view the timestamps in the tree visualization.
• stephen272 6y ago
  For anyone that uses emacs, there is an excellent plugin "undo-tree" that solves this problem in a slightly different way. Everytime you undo a series of actions and then perform a new action, it creates a branch in the "tree". You can then visualize the tree and move through it quickly your entire buffer history.
  • bobbylarrybobby 6y ago
    This was my first thought. A timeline is nice, but the problem with a linear undo history is that if you undo and then edit, you lose access to the state before you undid. A tree is clearly the right structure for undo history.
    • wtetzner 6y ago
      You could just append a new state to the end of the timeline when you “undo”, so you never lose history. This is how undo works in Emacs by default.
      • Brian_K_White 6y ago
        Heck it's how boring business apps handle bookkeeping data since forever. You never delete a record to correct a mistake, you create a new record to do it.
    • b3n 6y ago
      The tree structure is inherently flawed for storing undos when using features like undoing within a specific region, because the new state doesn't map to any previous node on the tree. By default, Emacs has a linear undo structure, while still allowing you to never lose history.
  • Guthur 6y ago
    I immediately thought of this, it is so good, like a source control-lite.
  • kleer001 6y ago
• pan69 6y ago
  If I remember correctly, Eclipse used to have (still has I guess) a feature were it would store code changes in a local history independent from your version control.
  • pestatije 6y ago
    Yes, definitely Eclipse local history. At least 10 years using it. What's interesting though is that such a feature would be off the radar for other editors and even the OP article.
• delgaudm 6y ago
  Not exactly the same, but as a voice actor the DAW is my "IDE", and configuring it save a time-stamped backup of the project file every five minutes has really saved my bacon several times, especially when the undo tree won't let me undo back to the state of 5 minutes ago.
• dilap 6y ago
  I've gotten in the habbit of just commiting very frequently. I have a git alias "git cam" that just commits everything with the message "nt". Then once I've got something working, I use GitUp (which makes it very easy to merge/split/rearrange commits) to collapse all the nt commits into one or two coherent "real" commits. Maybe a little clunky, but works well for me.
  • Quekid5 6y ago
    Basically same deal here, though using 'magit' and 'wip' instead of 'nt'. ('No text', one assumes?) Doesn't help with IDE settings and such, but that's such a niche situation that it doesn't matter at all for me.
• jolmg 6y ago
  > Why is it so hard to see code from 5 minutes ago while in the middle of a change? In vim you can do: :earlier 5m to see the code you had 5 minutes ago. > (1) If you go to a prior state and then make a new change, you can no longer redo and all those changes are lost. Vim makes a tree, so that doesn't happen with it. When you undo and make a new change, you're just making a new branch. u/Ctrl-r goes from leaf to trunk, but with g-/g+ or :earlier/:later you can walk the whole tree. Emacs similarly doesn't lose changes in this scenario, but instead of making a tree, it has a ring and undo is an action that can be undone. > (2) You can not see a side-by-side comparison of the previous version and the latest version. It's probably not complicated to make a macro or function where you go to a previous version, copy the buffer, paste it in a new one on a new window, return the original buffer to the state you were in, and diff the windows for that side-by-side comparison. A command like so suffices: :earlier 5m | %y | later 5m | diffthis | vnew | put | 1d | diffthis > (3) There is no visual indicator of where you are are in your undo/redo history. Not by default, no. :undolist provides some info, though, and the vimscript undotree() function probably provides all the state of the undotree. There might be plugins that somehow present this info in the interface. > (5) I have found many actions in code editors that do not get added to the undo stack (e.g., changing a debugger option), which caused me problems in the midst of an annoying bug. In vim, only stuff that changes the buffer is added to the undo tree. Navigation or changes of the state of the editor (e.g. editor options or vimscript variables) aren't added. Are there really editors where adding actions that aren't changes make sense? > (6) There is no indication of what steps were "big" or how long ago they happened. That's also true in vim it seems, at least how "big" they where. Each step does have a timestamp, though. > (6) It is tedious to backtrack one small step at a time. You can backtrack by however many steps you want. :earlier also supports specifying by seconds, minutes, hours, days, or file writes. Most cool of all is that vim can persist the undo history. I don't know how common that is among editors, but in vim you can go to a file you haven't opened in years and undo it all the way to its beginning.
  • nexthash 6y ago
    This is excellent... for Vim users. A lot of developers either are not willing or haven't gotten around to learning the complexities of Vim, and use other IDEs like JetBrains or Eclipse. This workflow won't work for them.
• neolog 6y ago
  In emacs, it's called magit-wip-mode.
• reactspa 6y ago
  I just searched and couldn't find a plugin for Atom called Yestercode. If there was one, I'd definitely use it.
  • azhenley 6y ago
    It isn’t public [yet]. You should check out our plug-in CodeRibbon though! Available for Atom. https://utk-se.github.io/CodeRibbon/ https://utk-se.github.io/CodeRibbon/
    • unityByFreedom 6y ago
      > It isn’t public [yet]. Ah hah. I'd like to use the code history slider plugin too. You've done well to identify a common problem many of us face.
• adjkant 6y ago
  I'm quickly reminded of Photoshop's "History" window and how it was one of my first adds to the standard environment setup to make it visually prominent in the top right of the workspace. You could quickly click up/down it and view the steps, but the functionality is in the end the same as undo/redo, where you lose the others once you make a change after walking backwards. I can't imagine it would be too crazy for IDE's to begin to add the same, per file at first but maybe also per project and then with saving some of those trees.
  • artificial 6y ago
    The actions can be embedded in the files as well. Pretty handy if you need to recreate something that's not been touched in a year.
• Moto7451 6y ago
  iTerm2 has an Instant Replay feature in case you want to see exactly what you were doing on screen in the past. https://iterm2.com/features.html https://iterm2.com/features.html
• nomel 6y ago
  Pycharm has a local file history that even allows showing history for a selection. I'm not sure what triggers the periodic records, but it has saved me multiple times.
• thitcanh 6y ago
  Does anyone know if there’s a good way to do this in VS Code? I often hold cmd-z until I get to some version and copy code from it. Ideally I’d like to have a separate window where I can see a previous version without affecting the current file/view. Before anyone comments, git doesn’t cut it for this because no one commits after every -+1
  • Mandatum 6y ago
    Like an ongoing stream of history where I have a slider I can drag to revert on-the-fly.. That'd be cool. I mean you could easily record and do this, but that doesn't copy-paste well. EDIT: And of course I read the article after reading the comments.. Haha, VS Code plug-in in 3.. 2..
  • de6u99er 6y ago
    Commit early, Commit often!
    • thitcanh 6y ago
      If I have to commit my whole undo history then I’m using git very wrong. I commit (even temporarily) to save progress, but only when it makes sense to so. Sometimes I don’t know whether I’ll need this specific version again in the future.
      • de6u99er 6y ago
        Git doesn't mandate to only commit useful stuff.
        • piyush_soni 6y ago
          But if there are more people in the team, it will be a great amount of noise they will have to go through before reaching any useful commit. Definitely not recommended.
          • 6y ago
• 83457 6y ago
  I remember using eclipse and a plugin for cfml years ago. If I help undo for a couple seconds to see old version and then redo for a couple seconds there was a 50/50 chance it would corrupt the code. If you haven't saved your latest changes or accidentally saving the corrupt code and have to compare to repo it gets old quick. Switched to Sublime.
• blunte 6y ago
  If looking at a source browser of a previous version of your code is not adequate to understanding how it worked, such that you wish to "rewind" to that version and run it, then your code is very poorly written. It is indeed difficult sometimes to understand our own code some time after it is written, but by following good practices (ideally functional, with mostly pure functions), it should be readable. I will venture a (biased) guess that one of the biggest challenges to understanding the code was the mutation of objects in the process. This is the #1 reason why functional programming is superior. With FP, you can grok what a function does and then comfortably forget about how it does it. It takes input, it produces output. Period. As long as you agree with the transformation algorithm, you can reduce that complexity to a one-line description. Even in non-FP-first languages, you can usually write pure functions. Some scenarios have enough performance demands that you must mutate things, but probably most situations can be approached with FP styling. All this rewinding and undoing is a distraction from the real problem. The real problem is that "it smells". It smells like a level of complexity that should not be.
  • saagarjha 6y ago
    Nope. Sometimes I’m rewriting something and I just want to see what the old code looked like before I changed it. There’s nothing smelly about that.
    • blunte 6y ago
      That's what a git browser is for. It's not like your code is gone forever, unless you are undisciplined.
      • saagarjha 6y ago
        I certainly don’t commit things every five minutes, so this doesn’t help.
        • blunte 6y ago
          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.
• stephc_int13 6y ago
  I am very surprised by this. I seldom use the control-z shortcut and I've been writing code for several decades...
  • blunte 6y ago
    Indeed. This sounds more like trial-and-error programming.
    • stephc_int13 6y ago
      Yes, and I've always believed that short-term memory is a very important mental training for a coder.
      • blunte 6y ago
        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.
        • kortex 6y ago
          Likewise. I have ADHD and even with treatment, I feel more like a GPU than CPU. Small functions, lots of static typing, IDE for autocomplete, and lots of FP style patterns. When I get thrown into an un-typed python codebase, my productivity grinds to a crawl, and I start having to do things like have a scratch pad with various versions to copy paste.
    • ggpp 6y ago
      What's the alternative? What should I be doing instead of cmd-z? > I'll Ctrl-A and Ctrl-V this into a new tab before it gets too messy I did this about 400 times today
• de6u99er 6y ago
  I learned very early in to "Commit early, commit often!" That being said, I don't think the reasons viven are honest: > When asked why they did this, they revealed they were trying to view some intermediate state of the code in the middle of a change. Looking at some GitHub repos, with one single commit, I believe many devs are afraid someone could see all their trial and error attempts and judge them. I oersonally am too lazy for the undo redo nonsense. Many of my final commits are mostly cleaning up the code. E.g. Refactoring so my code is like reading a story. I don't have an issue with people thinking I have OCD or something similar. My bigger issue is if I ever have to touch my code again, to waste time on trying to understand it. Or even worse, someone else not understanding it and asking me for help.
  • ggpp 6y ago
    > I believe many devs are afraid someone could see all their trial and error attempts and judge them This is certainly part of the reason I do it. Sometimes I'll start repos anew, without the "mistake" commits and branches, and add that version to my Github before I send the link to a potential employer.
    • Jtsummers 6y ago
      https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History https://git-scm.com/docs/git-merge https://git-scm.com/docs/git-merge C-f squash You can compress a series of commits into one with squash in git.
• blunte 6y ago
  Reading the comments, I'm stunned and disillusioned. Are most modern developers struggling to write code without this? If so, there is a fundamental problem that has nothing to do with levels of undo.
  • bsf_ 6y ago
    Indeed, I find this to be terrifying.
  • perryizgr8 6y ago
    What's the problem? I do this often.
  • comeonseriously 6y ago
    I'm so confused as to why anyone would do this.
    • ggpp 6y ago
      I write a lot of frontend JS with hot reloading make change => see result => cmd-z 1 time to fix result OR commit and keep coding oops, it wasn't really fixed. cmd-z 3 times and see if that works I know it's wrong, but what's right?
      • strictnein 6y ago
        > I know it's wrong, but what's right? Nah, it's not wrong. You're testing your code changes live.
        • ggpp 6y ago
          no it's webpack HMR (I know you're joking)
          • strictnein 6y ago
            Hmm... I actually wasn't. By "live" I mean in the developer's own browser.
• nhumrich 6y ago
  This is honestly the feature keeping me on PyCharm over VSCode the most. The "local history" feature of JetBrains IDEs is amazing. It saves on every blur, and has a diff viewer when comparing with history.
  • hans_castorp 6y ago
    > The "local history" feature of JetBrains IDEs is amazing. NetBeans has the same feature. I cranked it up to keep it for 30 days. Very handy. It's essentially an "automatic git" on every save.
• Wowfunhappy 6y ago
  Forget writing code, I do the mass-undo, mass-redo thing all the time when I'm writing prose. Even sometimes when I'm writing Hacker News comments.
• barnaclejive 6y ago
  Please don't make me use a slider. IntelliJ has local history, and I have that instinct to Cmd-S after every change. Problem already solved.
  • AndriyKunitsyn 6y ago
    What’s funny is that Ctrl+S does absolutely nothing in IntelliJ-based IDEs - all changes are saved automatically there, but we all still press it, because old habits die hard - and IntelliJ creators know this and don’t bind Ctrl+S to anything by default.
• egypturnash 6y ago
  > Want to know what we saw developers doing instead? They either duplicate code files or took screenshots of relevant code while in the middle of a change. Even I have done something similar before: I'm about to mess this up... I'll Ctrl-A and Ctrl-V this into a new tab before it gets too messy, and then I can put the window beside my editor to use as a reference. I even observed a professional developer with 20 years experience doing this! I do this kinda stuff all the time in my digital art practice. Duplicate a layer, hide the duplicate, start making changes. Does it work better? Awesome, delete the duplicate. Did my idea not improve it after all? Cool, delete the new version and rename the duplicate back. It's simple and reliable and builds easily on existing structures.
  • eyelidlessness 6y ago
    I made a similar comment and now I recognize that what we’re doing is branching outside version control. And I also recognize it’s still sensible to do, and that to the extent version control feels like friction this is yet another case where the interfaces to it aren’t good enough. And I don’t just mean “git cli is a bad ux” (though I mean that also), but that the whole world of version control is poorly serving rapid prototyping and other exploratory flows. It’s pretty likely aliases could serve some of this by wrapping a lot of fast paced idea checkpoints into a set of git actions. But it still would be disruptive for eg any intermediary file system side effects if it’s not faster than whatever watcher you have running.
    • vxNsr 6y ago
      if git was just ctrl+s or something similar (i.e. no more than a single keyboard shortcut sequence) then this whole problem would disappear, but because even in vscode it's "navigate to source control tab, ctrl+enter, enter enter(if something is not saved) "type some stuff" enter" it's too much to save "tiny" changes. not to mention reverts are a hassle. because of this comment I just decided to create a keyboard shortcut for commits to be alt+cc so now it's a little easier, I still need to type a commit message and accept save and stage, but at least it's all doable from the keyboard.
• dragonwriter 6y 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.
  • Hackbraten 6y ago
    > 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. Low-level plumbing commands, if the VCS has them, can help with that, e. g. `git commit-tree`.
    • AlexCoventry 6y ago
      Where would you want to use `git commit-tree`?
• cratermoon 6y ago
  I thought this was just a thing I did because I'm not a rockstar coder. I guess I'm average.
• Frost1x 6y ago
  I don’t think I've ever used this sort of time jumping with code. If I'm refactoring or testing a different segment I just comment out the original for visual memory reference and refactor based on the commented segment. Once I'm done, I chuck the commented section. It's nice to have the reference so I don't have to commit anything to memory.
  • alvarlagerlof 6y ago
    I do this too. Sometimes I'll duplicate the entire code and comment out the lower one as I write a new version or parts.
• jbluepolarbear 6y ago
  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.
• eyelidlessness 6y ago
  I routinely use copypasta and a quick rename as basically a stash/throwaway commit without breaking editing flow. It doesn’t stick around til a real commit because my tools yell about unused references. But it lets me keep and cross-reference a previous approach without undo history or going into version control mode when I’m exploring options.
• hzhou321 6y ago
  I found myself more and more often push a Pull Request just to have better visualization of the changes.
• mortdeus 6y ago
  so how do you handle the "undo make a change and no longer can redo" conundrum? Just have the branches in the tree of edits laid out flat in chronological order so that in order to bring changes back from the past you go to an earlier time, copy and then paste the changes to the alternative branch in the present? Idk I do think version control is probably a much better tool to sanely manage rapid workflow when working at scale on huge projects, I just think the problem is that there too many features and far to few people who actually take the time to learn how to use them effectively. To prove my point, the awk tool is super powerful and solves many "quality of life" problems developers begrudgingly deal with on a daily basis over and over again. Now lets see a raise of hands of people in here that can actually write an awk script one liner without referring to the manual? We have all these wonderful tools but most of us are too spoiled by having a mouse and powerful editors that we don't ever learn how to use them to improve our performance as developers.
• ta1234567890 6y ago
  Tangential to this. Does anyone know of an app/service like etherpad, but for handwritten notes? Would love to be able to replay notes that I write with the pencil on the iPad. I also feel it would enable a cool way of storytelling in which you can play with the way you write so readers get to experience the text in different ways. Imagine that as you are reading something all of a sudden the letters start getting bigger, or thicker, or star changing color. Anyway, just replaying handwritten notes would be nice.
  • Johnyma22 6y ago
    https://github.com/lovasoa/whitebophir https://github.com/lovasoa/whitebophir and it can be embedded in a pad for both text and hand written notes.
    • ta1234567890 6y ago
      Thank you, looks great. Does it have a replay feature? Didn’t see a reference to it on the readme or the wiki.
• keithnz 6y ago
  so..... the data this is based on is from https://sci-hub.se/10.1109/vlhcc.2014.6883030 https://sci-hub.se/10.1109/vlhcc.2014.6883030 which is 21 students programming. Seems a bit suspect the whole premise really. I don't really end up doing what this article outlines. I find a lot of programming studies are often done on what is immediately available... students, and I think this tends to not really be indicator of what experienced programmers do.
• wiradikusuma 6y ago
  [Works if source is versioned]. I usually use these 3 approaches in IntelliJ (IJ): 1. When a line is changed, IJ will show some marker in the left gutter. If I hover my mouse, I can see the diff. 2. Sometimes I peek Local History. 3. Sometimes I commit with random name e.g. "bla" so I can refer to that commit from time to time. When I'm done, I squash all the blas into 1 proper commit.
• tcfunk 6y ago
  I've just started using ZBrush recently, and one of my favorite ideas in this software is their timeline scrubber. You can just drag through undo/redo history to get back to the point in time that you want very quickly. I could see this being similarly useful in code.
  • loosetypes 6y ago
    Same. Perhaps a different time scale but I’ve considered doing this for files within a source code repository to better familiarize myself with the history. One interesting feature might be to be able to select any two commits such that you could diff them in isolation.
• hardwaregeek 6y ago
  Oh hey, I've built this! My version would watch code files and snapshot a diff every few seconds. It took a little work to tweak the constants to keep the watching performant, but it was super neat being able to replay code. The main problem I faced was that changes often occur in different places in the file, so the history replaying jumps around a lot. With some proper editor integration, I could see it being pretty useful. My version is super incomplete because I kind of lost steam when I couldn't figure out a really great reason why someone should use this, but hey, maybe it's worth another try: https://github.com/nicholaslyang/codemkin https://github.com/nicholaslyang/codemkin
  • whoisjuan 6y ago
    I would 100% use this! I do exactly what is described in the note. I use undo/redo a lot to traverse between two states of code and found this incredibly frustrating. Until this point I thought that was just a bad practice on my end, so never saw the need/opportunity for something like a state slider. Honestly never thought other people were using undo/redo like this.
    • IggleSniggle 6y ago
      I also use undo/redo like this and it has gotten me into frustrating locations on a couple of occasions... but still better than needing to break my flow to drop into making some well formed commit. I understand how to do WIP commits etc, but its helpful to do a rewind/fast-forward that includes all the character changes in-between the logical “blocks” of diffs. It often helps me recapture approaches to problems that I’ve already attempted.
      • Moru 6y ago
        I used to use the history function in NetBeans to do this. Has been around for several years apparently. Many other editors seems to have this function too.
• noetic_techy 6y ago
  Does anyone know of something similar that lets me watch data "flow" through my code at a human readable pace? I dont use ctr-z, Its surprising to me that people code this way, but I do tend to spend a lot of time thinking about how my data would flow through my current code set. It would be great if I could easily and almost cartoonishly visualize it. Anything like that out there? gdb is just to abrubt an harsh to use.
• 3np 6y ago
  I don't have this much at all.. But I do stage and commit pretty aggressively (with the occasional file-backup when I 'm lazy to branch and know I'm going to frewheel a bit) and look at local git diffs when I want to look back. Of course rebasing/squashing before pushing to a PR or merging.
• deleted 6y ago
  [deleted]
• TylerE 6y ago
  intellij does this quite well. Gives a browsable timeline of diffs, even.
• angry_cactus 6y ago
  I just comment out the old code while working on the new version. Surprised this isn't the obvious answer.
  • deleted 6y ago
    [deleted]
  • koonsolo 6y ago
    I seldom even do that. I just keep the code there, write the replacement, and then delete it.
• deleted 6y ago
  [deleted]
• indexerror 6y ago
  Jetbrains IDEs have a local history feature that provides snapshots with diffs and allows partial rollbacks. I only use it when experimenting with different approaches. Mostly I only use the "Local Changes" tab in the Git panel that shows the diff compared to the last commit, or "Compare with branch" to see the overall changes relative to the base branch.
  • beders 6y ago
    Local history saved my sorry butt yesterday when I thought I lost all my files due to a git-related accident. But Local History still had all my changes and restored my files. Unclear why this isn't baked into the OS nowadays. It's not like we don't have enough disk space ;)
    • tikhonj 6y ago
      I just saw something similar on Twitter[1]: a script that takes a ZFS snapshot after every command. This lets you jump back to the state of the whole filesystem after every single command that you ran, giving you a sort of global history. I figure you could adapt that to something a bit more restrained that you could use on an ongoing basis to have a "Local History"-style feature for your whole OS :). [1]: https://twitter.com/grhmc/status/1362222849662935041 https://twitter.com/grhmc/status/1362222849662935041
      • leonim 6y ago
        That looks amazing. I've used NetApp NFS filesystems that provided user level snapshots, where it automatically created snapshots of files. It wasn't after every command, but at regular intervals. You could access the files under `.snapshot` directory. Searching now, it looks like this is part of NetApp ONTAP, and managed by a snapshot policy.
  • freeqaz 6y ago
    I came here to write this comment. I use this feature often and, like the sibling comment, it has saved my butt a ton! I love JetBrains IDE with Vim bindings
• jonnycomputer 6y ago
  When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I commented out: >though his companions jogged just behind him, he would have barely seen them at all had he look. They ran, with their heads down, attentive only to their feet slapping the muddy earth, tracking the path they followed, their breath ragged. and wrote this, using the commented-out text as a reference: The fog was now so dense that he could see nothing ahead of him. He ran with his head down, breath ragged, attentive only to his feet slapping the muddy earth, tracking their path. His companions followed close behind.
  • mssundaram 6y ago
    I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.
    • sslayer 6y ago
      Commenting is the answer. It stays until I'm certain I no longer need it.
    • jonnycomputer 6y ago
      As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.
      • powvans 6y ago
        Yes! Just today I was wishing that I could have syntax highlighting on commented code that I was refactoring. Just dim it a bit instead of turning it all grey.
• grimgrin 6y ago
  a workflow i'm pretty hooked on is: using vim w/ git-gutters plugin, which shows the state of a line (+-~), and so you can stage and unstage these hunks with mappings. so maybe you unstage a whole hunk to see what its original state was, but then just do an undo to return it. this is technically many undos in one there's some more conveniences here, but this is one that stands out regarding "many undos ago"
• bondolo 6y ago
  Netbeans has had this feature for about a decade and I use it all the time for exactly the reasons suggested. I was pleased to see that IntelliJ has the same feature. The resolution doesn't need to be more than a couple of minutes. Netbeans will keep a couple of weeks of local history and prunes the old history down to one or two snapshots a day. It can get a little confusing if you are checking out vastly different versions of the same file from different branches since it doesn't record what branch you were working on at the time, but it nonetheless very useful.
  • Aeolun 6y ago
    > It can get a little confusing if you are checking out vastly different versions of the same file from different branches I see that as a feature, not a bug. I’ve been saved countless times when I accidentally messed up my git or local state.
• WesleyJohnson 6y ago
  Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming in with their own anecdotes, or tools they've discovered that help alleviate the same issue in other ways. If you've never had to UNDO/REDO a block of code to revisit a previous state before moving forward again, kudos. But suggesting those that do are somehow going about programming in the wrong way is not constructive.
  • JoeyJoJoJr 6y ago
    Development often times entails a lot of trial and error, and there is nothing wrong with that. If you have fast iteration cycles, you can fail many times before you settle on an optimal solution.
    • collyw 6y ago
      That usually depends if you are writing something from scratch, or wrestling with other peoples libraries.
  • balp 6y ago
    I try to rememberf my local history view in the editor, it sometimes give a better overview.
  • tluyben2 6y ago
    > the wrong way is not constructive. Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It both works, but I have several converts who now work like me and actually enjoy it more (not to mention far less chance of RSI). Whatever works for you I would say. What is a bad thing though is that it also has to do with the pressure put by WFH in some companies and sites like Upwork => a lot of 'managers' (and sorry, I cannot say anything positive about these people, but their number increased rapidly during Covid in my experience) measure productivity of an employee by keystrokes, screen changes and # of commits. Even though I finish more tasks in a day than most of my colleagues in our projects, according to those metrics, especially keystrokes and screen changes, it looks like I'm doing 'nothing'. Whatever.
• brunocvcunha 6y ago
  Piazza represent
• spiznnx 6y ago
  I'm fairly used to using basic undo/redo as a timeline already. I spam "undo" often in vim just to yank something into a scratch window. I might accidentally make a change that breaks my redo path back to the present, but thankfully that's a pretty rare occurrence for me (and I can always recover with "g-"). Good enough for me!
  • lilyball 6y ago
    Vim is the only editor I’ve used that has a branching undo model. I know there’s a UX problem there but I don’t understand why more editors don’t support this.
• nilsbunger 6y ago
  Undo/redo doesn’t affect the clipboard, so I find myself often undoing back to some state, using cmd-c to grab something I wanted, then redoing to the present.
• lilyball 6y ago
  In Git you don’t have to actually commit, you can use the staging area. It’s something I do rather often. I’m going to make a non-trivial change and I’m not sure if it’s the right approach, so I `git add -A` first, make my change, and then `git diff —-cached` to review it. This is especially useful when doing things like running formatting tools, so I can see what the tool just did. And it doesn’t require making any commits. Having said that, this approach only works if I know up front that I’m going to want to compare the code. Far more often is making a change and then realizing I want to see the old version. A history timeline would be extremely useful here.
  • nilsbunger 6y ago
    Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push. Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together
    • gorgoiler 6y ago
      If you work on a branch you can push them to your remote repo anyway. Good for backups or if you move between hosts for any reason (I do this all the time as I prefer static workstations for focus and work/life balance.) Branches rightly became a bit of a dirty word over the last decade. In a fast moving collaborative codebase the pattern you really want to avoid is using a long running feature branch — one that remains uncommitted to trunk for ever more uncomfortable periods of time. Branches themselves — the VCS technology part — are incredibly useful when used fluently.
    • sixstringtheory 6y ago
      You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)
• samsaga2 6y ago
  You can just use emacs and undo-tree. You can also save the undo history in a file and you will have all the file history forever.
• oscribinn 6y ago
  vim users just can't stop winning
• watwut 6y ago
  Eclipse keeps local history and you can see changes as you made them.
• craigds 6y ago
  In Sublime Text I actually use a quick Undo-then-Redo to navigate, of all things. I'll be typing some code and realise I need to check whether the imports at the top of the file are correct. So I'll Cmd+Up (go to the top of the file) and see that yes, they are correct. Now I have to get back to where I was. A quick Cmd+Z,Cmd+Shift+Z does the trick - Undo (takes me back to the code I was editing, and undoes some of it) and Redo to put it back to how it was. Works well, but would mess up this researcher's statistics. (I absolutely do also use the undo stack for looking at the last few minutes of history too, that's really valuable)
  • wodenokoto 6y ago
    There is a navigational back command, that moves your cursor back in time, just like a webbrowsers back button. cmd+-, if I remember correctly.
    • caillou 6y ago
      `ctrl + -` is a good short-cut. But, often times I have jumped around many times, or only scrolled. It doesn't work in these situations. Whereas `undo` `redo` reliably brings me back to the place of last input.
      • wodenokoto 6y ago
        What ever works for you. To return to scroll position I click up then down or left then right. You can use `ctr + -` to also jump between documents. So if you’ve jumped to a function definition in another document the back shortcut can take you there.
  • teddyh 6y ago
    > Now I have to get back to where I was. In Emacs, you can often use C-x C-x for this, since many movement commands which moves far away, like beginning-of-buffer, sets the mark at where you moved from. So C-x C-x moves you back. If this does not help, i.e. you have moved several times, you can almost always get back by repeatedly doing C-u C-Space until you find yourself at the correct place again.
• ryanwhitney 6y ago
  While it might get out of hand from normal undo/redo code flows, Drama (a design prototyping app similar to Principle) has an awesome history UI with branching. https://www.drama.app/documentation/history https://www.drama.app/documentation/history
• williamstein 6y ago
  In CoCalc, one of the foundational ideas is that it should be very easy to see code and Jupyter notebooks from 5 minutes ago. Hence every editor in CoCalc includes a TimeTravel button, which you click on to get a side-by-side view of your file (or notebook) and a slider that lets you go back and forth in time at high resolution. I designed CoCalc this way because when I taught data science classes, I would walk around a classroom while the students were doing an in-class exercise and they would often say to me "I had this part figured out 5 minutes ago, but I messed it up." Some people (including me!) who get used to working this way get very addicted to it, and can hardly imagine working any other way. This is vastly superior to depending on undo/redo, and I use it all the time when doing deep coding projects. It's also useful for collaboration, since it makes it easier to figure out what somebody else did with a file or notebook.
• redcat7 6y ago
  wow, so my assumptions that coders dont design and draft solutions, but type in furiosly code to make it work where true. i recently begin to believe the teaching how to create software is fundamentaly flawed. now i have more evidence. wow.
• jawzz 6y ago
  My school’s JS IDE [1](“JavaScript without the bad parts”) has a history feature that is just a scrolling list of thumbnails of the code at every change. The IDE doesn’t have many features overall, but the history is actually very nice and natural and feels like it should be standard in any IDE. [1] https://www.ocelot-ide.org/ https://www.ocelot-ide.org/
  • theaussiestew 6y ago
    I'm curious, does it actually use the local machine to compile files? Or is the compilation done on some remote instance?
    • jawzz 6y ago
      It’s built off of Stopify[1], which compiles “from JS to JS” and runs on the client side. [1] https://www.stopify.org/ https://www.stopify.org/
• ulnarkressty 6y ago
  Auto History for Visual Studio is excellent for this use case. https://devblogs.microsoft.com/visualstudio/auto-history-extension-in-visual-studio-2013/ https://devblogs.microsoft.com/visualstudio/auto-history-ext...
• nathias 6y ago
  in vim: :earlier 10m, or short :ea 10m and :later 2h, or short :lat 2h
• ankit_mishra 6y ago
  For me "Local History" feature in WebStorm solves the issue. https://www.jetbrains.com/help/webstorm/local-history.html https://www.jetbrains.com/help/webstorm/local-history.html
  • jansan 6y ago
    This feature is absolutely outstanding, I use it all the time. Unfortunately they buried it in the "File" menu recently. It was so much easier to reach when it was unter "Version Control".
    • pewu 6y ago
      It's also accessible from context menu in the editor, I use it from there.
    • cribwi 6y ago
      You can assign a custom shortcut to it via Settings > Keymap and then the action "Main Menu > File > Local History". I myself have assigned the shortcut control+shift+=
      • jansan 6y ago
        Thanks, did that. I decided on Alt+Z, because Ctrl+Z is Undo, so I though this makes sense.
        • matsemann 6y ago
          And Ctrl+Alt+Z is revert changes. Either the whole (or selected) file, or the current block you're in. I use it all the time.
  • electrum 6y ago
    This is part of the IntelliJ IDEA platform, so all of the JetBrains IDE products have it. I don’t use it often, since I normally rely on Git, but it’s saved me several times after I accidentally deleted a file or made a mistake with Git.
• beermonster 6y ago
  https://vimtricks.com/p/vimtrick-time-travel-in-vim/ https://vimtricks.com/p/vimtrick-time-travel-in-vim/ Commit often and use reflog? https://www.w3docs.com/learn-git/git-reflog.html https://www.w3docs.com/learn-git/git-reflog.html
• dflock 6y ago
  Before Microsoft bought GitHub and killed Atom, they were working on Xray[1] & Memo[2]: > Memo is an operation-based version control system that tracks changes at the level of individual keystrokes and synchronizes branches in real time. [1] https://github.com/atom-archive/xray https://github.com/atom-archive/xray [2] https://github.com/atom-archive/xray/tree/master/memo_core https://github.com/atom-archive/xray/tree/master/memo_core So, it would fix this problem, and also enable real-time collaborative editing, had it been completed.
  • thunderrabbit 6y ago
    M$ killed Atom?? It ostensibly seems fine, updated today. https://github.com/atom/atom https://github.com/atom/atom
• cnskskhdkeke 6y ago
  Why is this a problem worth solving? I don't recall this being a bottleneck in my recent work.
• geocar 6y ago
  Because you forget what you can’t see. This is the same way that whitespace and long variable names make code harder to read and reason about: simply because you can see less of it.
• lloeki 6y ago
  For this I use: a) git add and git diff --cache b) :w and git diff (or git diff HEAD to compare a+b) c) nmap <leader>d :w !diff -u % -<CR> so that’s three diffs / four different stages. If I need more I also don’t refrain to use sequences of temporary commits I rework with git reset master + git add -p and/or git rebase -i So overall there’s no fear of early commitment to be had.
• zrkrlc 6y ago
  This would actually work for text editing in general. When I’m writing essays, sometimes things don’t come out right and it helps to compare them with newer attempts.
• Moru 6y ago
  NetBeans have something very similar to this. You can get a diff on all changes to a file, both from your commits and from just a timeline. You can click to transfer old code to the new version blockwise as needed. No need for copy-pasting. It's set to delete history after 7 days but can be changed to never. Haven't realy used it much last few years though so don't know if it's still there.
  • pvorb 6y ago
    The same feature is available in IntelliJ IDEA and likely in the other JetBrains IDEs.
• unnouinceput 6y ago
  Oh, this is a neat idea. I can easily do this for everything using hooks. Just a minimal GUI, target window to hook into (handle to it) and then every keystroke into its own. Combine this with a multiple view/diff and you have a good version control on the fly. Be right back, I'll go implement it right away.
• petters 6y ago
  > I'll Ctrl-A and Ctrl-V this into a new tab before it gets too messy, and then I can put the window beside my editor to use as a reference. I even observed a professional developer with 20 years experience doing this! This seems... fine?
• deleted 6y ago
  [deleted]
• deleted 6y ago
  [deleted]
• gitowiec 6y ago
  I would love to see this in my WebStorm! I often did premature commitment and then I used undo and redo. Then I learnt that it is hard to code. Now I am slower in decisions which does not quite help me be productive but calms down premature commitment.
• kerblang 6y ago
  My goofy lil' homemade editor does it this way: If you go back in the past and change it, the future becomes the past. This might sound confusing, but effectively it means that the undo stack contains the actual history of "what happened". This means you can hop to any past or future state linearly with undo & redo alone. I just find this easier than navigating tree GUIs and things that aren't worth the trouble to me. It can still lead to a bit of mental gymnastics in extreme cases. https://github.com/zaboople/klonk https://github.com/zaboople/klonk Note that in theory this can cause an exponential growth of the undo/redo stacks because it makes an upside-down copy of the future when you change the past; but in practice it's never been an issue. I was thinking of adding a feature to navigate back to "last change-the-past", which wouldn't be hard. It at least makes more sense than most science fiction time-travel plots...
• m3at 6y ago
  I've not seen it mentioned yet so I'd be remiss not to link to undo tree [1] for vim. I tend to put my list of plug-ins on a diet over time, but undotree is one I always kept! Having a visual of the history (like in the article) make it much easier to do a quick back and forth through time. Also for fun, consider having your scroll wheel traverse time instead of space [2]. [1] https://github.com/mbbill/undotree https://github.com/mbbill/undotree [2] https://xkcd.com/1806/ https://xkcd.com/1806/
• kruxigt 6y ago
  What I usually do is make a copy of the function that I'm working with and give it another name. Then i can compare both the contents and the result of the two functions.
• progfix 6y ago
  > Why is it so hard to see code from 5 minutes ago? Because you aren't using Vim: ":earlier 5m"
• mebassett 6y ago
  if you use vim, you can do things like ':earlier 5m' to see code from 5min ago. in fact, vim keeps a whole undo tree available, and some plugins will let you visualize it. https://github.com/mbbill/undotree https://github.com/mbbill/undotree
• xmodem 6y ago
  My favorite IntelliJ feature is that it tracks the full history of the files in your project, losslessly and independently from your VCS. You can just go and pull source from Local history, from 5 minutes or 5 days ago (I'm not sure how far back it goes, I've never needed more than a week). Not something I use often but as a last ditch effort to find code that I've spent hours or days on and subsequently lost to a git mistake, or reverted thinking I was going to use a different approach, it's worth the price of entry for the JetBrains tools alone.
  • est31 6y ago
    Personally I just use git for that. Even if I'm not 100% happy with some solution, I put it into a commit and then do subsequent improvements, or just remove it again entirely.
    • dd82 6y ago
      this is indeed useful, but what the parent comment is referring to is it also stores with local history outside of git. So you can check both git history for a selection, as well as local history that exists since your last commit.
      • est31 6y ago
        I use my editor's history heavily, but never needed something beyond the Ctrl + Z / Ctrl + Shift + Z history to access things done immediately prior. If I'm unsure if I'll need some approach in the future, I make a commit. I've become increasingly good at this prediction.
    • toyg 6y ago
      But then you end up having to clean up your git history before committing to the shared branches, with squashes and rebases, which is annoying.
      • TOGoS 6y ago
        Not as annoying as learning to navigate some IDE-specific way of doing it. And I usually end up cleaning up my commits, anyway. Also, if I've committed things, then I have commit hashes to refer to in my notes.
• AzzieElbab 6y ago
  IDEAs local history to the rescue
• deleted 6y ago
  [deleted]
• cwmartin 6y ago
  This sounds like it could be an incredibly useful feature in IDEs. It reminds me of the timeline in Fusion 360 [0] which allows you to scroll back through time, make a change to a feature in ‘past’, and then jump back to the present state of the project. [0]: https://www.autodesk.com/products/fusion-360/blog/wp-content/uploads/2016/06/timeline.gif https://www.autodesk.com/products/fusion-360/blog/wp-content...
• deelly 6y ago
  I want to add one tool that (looks like) still has no mention there: clipboard manager. Clipboard manager allow you to store all clipboard history. Thats not the best solution, but at least for me with it I able to copy some original and intermediate states of code few times and return to it anytime in the future.
• aulin 6y ago
  I refuse to believe anyone worthy of calling himself a developer takes screenshots of the screen to save intermediate code changes
• jmull 6y ago
  Advantages to this approach to referring to an older version of code that alternatives may not have: * works well entirely through keyboard shortcuts (especially useful when editing code) * the shortcuts are standard so you already know them and have them committed to memory * works across editors * high granularity of control over exactly which version of the old code to refer to Undo trees seem like the best alternative, since it can be done strictly as an extension to convention undo/redo... a little HUD can let you see your current location in the tree and the normal keys can be used to navigate it, with the addition of one more shortcut to change branch. The "separate window with panning control" suggested in the article seems awful to me.
• mthwsjc_ 6y ago
  vim has a very versatile undo function, including undo the last n minutes/hours/days of edits. it also has undo branches. e.g. `:earlier 5m`
• PaulHoule 6y ago
  Jetbrains IDEs have a local history which helps for that.
• bogwog 6y ago
  I didn't even realize I did this until reading this article. I think the issue is that the undo/redo concept is inadequate. The author's solution of a persistent, read-only history seems like a step in the right direction, but that seems like it's much too slow of a workflow to beat out CTRL+Z/Y/Shift+Z, which is muscle memory for most. Maybe we need something like a hyper lightweight git that can be controlled via keystrokes. It's really disappointing how so many interfaces have been stagnant for so long. It sometimes feels like the only software difference between a computer from 2021 and 2001 is that the graphics and animations look nicer, but otherwise is just more of the same stuff.
  • kuschku 6y ago
    That's what IDEA has integrated as "local history" and I use it every day for this purpose.
  • augusto-moura 6y ago
    Undo/Redo shortcuts and a button to see the history in a timeline, my biggest problem is writing while in a undo state overrides the redo stack. Jetbrains has a Local History functionality, by it has a linear timeline instead of branching like the author plugin
• Jeff_Brown 6y ago
  > ... introduces a problem of premature commitment, 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 Why is that a problem? Just commit, as many times as you want, to a throwaway branch.
• mavsman 6y ago
  I used to work on Cloud9 IDE and it had a feature like this. It's now probably still in AWS Cloud9. It's tremendously helpful and magical when you have it. Having a We had considered ways to expand on this feature for educational purposes by adding audio to create a tutorial but never could allot resources for this.
• hans_castorp 6y ago
  I have simply enabled "Local History" in NetBeans and can go back (with diff) to any time until 30 days ago (in addition to what Git gives me).
• wicket 6y ago
  It's not so hard, the author is just using the wrong OS. VMS saves new files versions for every disk write and now that it runs on x86 [1], there is little excuse to not use it. :D [1] https://news.ycombinator.com/item?id=26169179 https://news.ycombinator.com/item?id=26169179
• eithed 6y ago
  My primary editor is VSCode, but I've got Sublime open as well. When making changes part way, I just cmd+x -> cmd+v to Sublime. This way if something doesn't work out I don't need to undo to whatever it was that was working. If operating on multiple files I can have the snippets in the same tab, or different tabs in Sublime.
  • beermonster 6y ago
    Check this out then. It’s like git-timemachine for Emacs but for VS Code https://marketplace.visualstudio.com/items?itemName=bee.git-temporal-vscode https://marketplace.visualstudio.com/items?itemName=bee.git-...
• constantine42 6y ago
  Code smell, poorly factored. I almost never do this, but when I do, it's almost always because the code is already messy. This can vary by problem domain and language. I see some examples of regex below and I can agree with that, because regex is difficult to read.
• bennysonething 6y ago
  I always think about that thing John carmack said that when working on quake he could rewrite the whole thing from memory. My memory is terrible. I think to be really good takes an excellent memory. :(
• SharpNinja 6y ago
  I have had this same idea and would love to collaborate. I can see tgis as either an extension to be added to existing IDEs or an enhancement to the Monaco Editor. I see it as a product named Multiverse Editing. You start off coding in the prime universe. Each Undo places a node on the current universe's timeline. If you continue editing you are still on the prime timeline. But you can click on any node in the timeline to go back, and editing from there branches to a new universe with its own unique timeline. Each node represents either complete before and after code for the current timeline and a pointer to the root of one or more new universes. you can select any two or three nodes and perform a merge which results in another new universe branching from the source (left) node of the merge. A database will exist for each source file, each representing their own multiverse. Source control events would become nodes on the timelines such as branches becoming a new universe and merges collapsing universes together. Ideally the database would be in the SCP and not the editor, though that might get slow, nut that would preserve the complete edit history for a file. Each node would have metadata where the developer could add notes in MD format, etc.