Live data from Hacker News

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

web.eecs.utk.edu

101–110 of 424 posts

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

#101

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

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

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

#102
post #50

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.

Likewise. This whole thread is totally bizarre.

The closest imaginable thing I might do is wrapping some block of code in an if(false) {..} or #ifdef it out, when I'm refactoring and feeling unsure about my changes. But is that even the same thing that we're talking about here?

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

#103
post #57

Earlier quoted context omitted.

Another cool thing about undo in Emacs is that it's context aware. By default, you can select any block of text and the undo command will cycle through the changes only from that region of your buffer.

whoa this is cool does it understand syntax boundaries like curly braces / functions? ('undo within function' would be key). or just line #?

Regions in emacs do not need to consist of whole lines.

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

#104

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.

Newb emacs user here. Heavily reliant on spacemacs and tutorials and copy-paste, but I use it often. The undo-tree terrifies me.

It’s easier to mentally map that the default behaviour undo/redo for Emacs (which is not unreasonable, just complex).

The source for undo-tree contains documentation which very effectively describes the way the library works with examples and comparisons with how Emacs does things by default: https://gitlab.com/tsc25/undo-tree/-/blob/master/undo-tree.e...

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

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

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

#106
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

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

#107

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

One thing I think would help this is a dual repo setup with the local dev-only repo automatically committing on save (or if your watch is expensive committing unsaved editor state on pause). The repo could be short lived if you prefer (eg new per baseline repo branch or editing session) or a long lived series of stashes. But its history would be built into the editing experience and separate from the normal version control flow. I don’t think it would necessarily work for everyone but it could certainly fit how I work in exploratory mode without breaking my editing flow.

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

#108
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…

> Are there really editors where adding actions that aren't changes make sense?

Adobe Photoshop is one. Selection changes don't modify the document at all, but they are part of the undo stack. That's because selecting a part of an image isn't as trivial as selecting text.

Sometimes I wish the current selection could be automatically saved in the file too so you could start where you left off if you were halfway through making a complicated selection (I know you can manually save selections, but that's an added step).

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

#109
post #101

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

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

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

https://git-scm.com/docs/git-merge

C-f squash

You can compress a series of commits into one with squash in git.

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

#110
post #64

Earlier quoted context omitted.

Yes, and I've always believed that short-term memory is a very important mental training for a coder.

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.

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.

Post reply on HN