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
Why is it so hard to see code from 5 minutes ago?
291–300 of 424 posts
Re: Why is it so hard to see code from 5 minutes ago?
#292My 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.
Re: Why is it so hard to see code from 5 minutes ago?
#293When 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…
My approach is similar to this, except for whole functions/classes I tend to just create a new one with a version number. e.g. DataContext => DataContext2.
When I'm satisfied that DataContext2 does everything that DataContext does, I delete old one and rename DataContext2 => DataContext.
The risk here, is that sometimes it's not possible to migrate everything to the new version and you end up with multiple old versions lying around, i.e. technical debt.
Re: Why is it so hard to see code from 5 minutes ago?
#294My 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 gi…
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.
Re: Why is it so hard to see code from 5 minutes ago?
#295Does 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
Commit early, Commit often!
I take it you didn't read the article so.
Re: Why is it so hard to see code from 5 minutes ago?
#296When 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 used to work like that. Now I don't. (And I would advise against it.)
Use version control, do lots of small of commits, use diff. Have a fast edit, build, test/run cycle. If you don't have it then spend the time setting it up.
Re: Why is it so hard to see code from 5 minutes ago?
#297When 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 used to work like that. Now I don't. (And I would advise against it.) Use version control, do lots of small of commits, use diff. Have a fast edit, build, test/run cycle. If you don't have it then spend the time setting it up.
My employer told me a 23-step code submission process, across five tools, that takes four days to run all the tests is fast enough. Is that fast enough?
Re: Why is it so hard to see code from 5 minutes ago?
#298IDEAs local history to the rescue
Re: Why is it so hard to see code from 5 minutes ago?
#299Earlier quoted context omitted.
The theory is that given enough code, any antipattern that compiles will make its way into real use, and therefore the only way to make people stop using an antipattern is to refuse to compile it. Go trades inconvenience in the short term for removing an entire class of bugs and raising the readability floor of bad code.
That's an insane approach, eslint solves this just fine and is fully configurable for almost any style preference.
All Go code everywhere never has unused variables, never has unused imports, and is formatted similarly. But, when you're debugging a function, you can't leave unused variables or imports lying around.
It's a tradeoff. I don't think either side of the tradeoff is insane.
Re: Why is it so hard to see code from 5 minutes ago?
#300Earlier quoted context omitted.
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.
> one of my colleagues remarked that he never thought to view the same file alongside itself I do this all the time in Emacs, usually to see two parts of the file that normally are too far apart to be visible at the same time. Collapsible sections can do similar, but to me it's quicker, more natural and more flexible to just split the window.
Another good trick in emacs (if using git and magit) is `magit-find-file HEAD `, then you can edit in one window and see the old version in the other