Live data from Hacker News

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

web.eecs.utk.edu

131–140 of 424 posts

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

#131

Earlier quoted context omitted.

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.

I am one of those "not willing" people. I encounter the same issue discussed here without even thinking about it, and solve it as such: 1. Realize I need to check how my new code looked like 5 min back. 2. Copy full file into clipboard, undo by a few steps 3. Do a temp commit on GitHub desktop 4. Paste the new code back and look at the diff on GitHub desktop, and if needed undo the temp commit from above. Is this mor…

It's not as hard to learn as people say it is. It's just weird at first because it's modal and different than what they're used to. You can get away with using it pretty naively and still get a productivity gain.

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

#132
post #111

Earlier quoted context omitted.

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?

Hello from the bizarro universe of people who do this all the time and can't imagine the opposite. Do you never rewrite some code only to realize it didn't precisely capture all the edge cases of the thing you rewrote? In those cases I use the git gutter in VSCode to view what the old code looked like and compare and contrast to the new version to see what I missed. It seems to me that that's the same as what these e…

If there’s a specific implementation that’s especially hairy, I’ll just copy that block and comment it out before continuing. Instant reference. And if I’m rewriting more than 10 or so lines at a time of complex business logic, something is wrong.

But also, `git diff`.

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

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

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

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

Wow, I have a lot of vim learning to do. Your pipeline is far beyond my level.

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

#135

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

Yeah that is the simple and very effective solution of this whole problem. If I had to use I would use something like this.

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

#137
post #73

Earlier quoted context omitted.

I certainly don’t commit things every five minutes, so this doesn’t help.

(Ok, looking at your profile and your background, I must be missing something. You surely don't need 5 or 10 minute history of code to know what you are doing.) Please help me understand what I am missing from this conversation!

A common example from my work: I’m doing layout code, so I need to clean up some constraints that are broken. Often this a fairly manual process where I change some code and run it to see how it does, and then adjust the code as needed. Sometimes I need to change my strategy (instead of manually pinning this view, I can put it in a stack view…) and this requires me to change a couple lines of code. Then I run it and it breaks in a way that makes me realize that this direction was a dead end, so now I want to go back to where I was five minutes ago. Or, sometimes this is the way I wanted to go but in the process of rewriting it I forgot to carry over a constraint, so I want to see how I was doing it before and pull out a line or two so I can include it in the new code.

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

#138
post #111

Earlier quoted context omitted.

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?

Hello from the bizarro universe of people who do this all the time and can't imagine the opposite. Do you never rewrite some code only to realize it didn't precisely capture all the edge cases of the thing you rewrote? In those cases I use the git gutter in VSCode to view what the old code looked like and compare and contrast to the new version to see what I missed. It seems to me that that's the same as what these e…

Exactly. Sometimes you start heading down a change path, and as you discover more, you realize there is a better solution. You want to save some of your concepts, but discard others. That's what this helps solve.

Git stash can be helpful. Stash your "wrong direction" change, then apply just the good chunks from your stash.

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

#139

Earlier quoted context omitted.

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.

Git doesn't mandate to only commit useful stuff.

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.

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

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

Wow, I have a lot of vim learning to do. Your pipeline is far beyond my level.

| in vimscript is like ; in other languages. I'm not sure pipeline is a good name to call it. It's just a list of commands run in sequence.
Post reply on HN