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 com…
Why is it so hard to see code from 5 minutes ago?
141–150 of 424 posts
Re: Why is it so hard to see code from 5 minutes ago?
#142using 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"
Re: Why is it so hard to see code from 5 minutes ago?
#143Earlier 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 #?
For eg, see https://www.johndcook.com/blog/2017/08/09/selecting-things-i...
Re: Why is it so hard to see code from 5 minutes ago?
#144Earlier 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…
Yes, git diffs help, but once I’ve passed a parameterized suite of unit tests, never needed to undo/redo. Maybe not perfect the first go, but only need one/two tries to working code. Then refactor for readability.
Re: Why is it so hard to see code from 5 minutes ago?
#145Earlier quoted context omitted.
It might not be exactly what you're looking for, but I saw this linked on Twitter recently and have been meaning to try it out, so maybe worth a look? https://marketplace.visualstudio.com/items?itemName=Wattenbe...
This solves another problem I had, so I’ll try it, but it’s completely unrelated to edit history.
Re: Why is it so hard to see code from 5 minutes ago?
#146Earlier quoted context omitted.
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?
#147Earlier quoted context omitted.
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?
#148Earlier quoted context omitted.
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?
#149Reading 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.
Re: Why is it so hard to see code from 5 minutes ago?
#150When 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 com…
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.