Live data from Hacker News

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

web.eecs.utk.edu

11–20 of 424 posts

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

#11
post #10
post #7

Earlier quoted context omitted.

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.

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.

Fantastic, downloading the latest version now!

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

#12
post #2

jetbrains IDEs have a local history feature that seems to do this

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.

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

#13
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.

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

#14

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.

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.

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

#15
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.

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

#16
> 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.

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

#19
post #16

> 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 tru…

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.
Post reply on HN