Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

web.eecs.utk.edu

Post reply on HN
Print view View original

381–390 of 424 posts

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

#381

Post by jmelloy »

amichal wrote: post #372
jstimpfle wrote: post #352

Earlier quoted context omitted.

People are getting way to hung up about their commit history in most cases. If you're just experimenting, even "asdf" can be a totally fine commit message. And it shouldn't be hard to come up with something at least a little more descriptive in You can edit the history later when it's required by somebody else working on the code. Or you can just not care. 99% of the value of your git repo should be in the most recen…

Looking at other people's code I vastly prefer a feature branch with a summary name of the feature "new-checkout-flow" or whatever and then the commits as they where without squashing/rebasing. Mine tend to have quite a few commits cycling through: - Stub in [classes/models/etc] for checkout flow - Add basic test coverage - Fix my API for easier testing - Decouple foo from bar in new flow - New checkout flow mostly t…

I agree. I also think commit messages get more detailed the further along the process is, and the less code you change.

“Added unit tests and stub out api” (50 files) vs “fix bug when files are added too quickly” (1 file, 3 lines)

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

#382

Post by happimess »

jonnycomputer wrote: post #351
quacked wrote: post #345

Earlier quoted context omitted.

Huh, I thought your first example was much more poetic. The vaguely run-on sentence does a much better job of evoking what's happening in the scene.

Thanks. I'll think about it.

For the record, I think the second version is a clear improvement.

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

#383

Post by strictnein »

ggpp wrote: post #358
strictnein wrote: post #115

Earlier quoted context omitted.

> I know it's wrong, but what's right? Nah, it's not wrong. You're testing your code changes live.

no it's webpack HMR (I know you're joking)

Hmm... I actually wasn't. By "live" I mean in the developer's own browser.

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

#384

Post by jolmg »

john4532452 wrote: post #284
jolmg wrote: 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 seems cool. Is there an equivalent feature in emacs ?

What particular feature? :earlier 5m? I'm afraid not. Emacs' C-/ acts like :earlier/:later/g-/g+ in that you can navigate the history across undos, but there's no support for specifying by number of minutes. I don't know if there's a package for it though. Evil-mode (vim emulation in emacs) doesn't seem to have support for that either.

I can't imagine it'd be that complicated to add it though, if you really want it. I think it'd just be a matter of hooking to the undo function and maintaining a list of timestamps for each item added to the undo list, then adding a command that lets you specify the number of minutes and figures out the correct undo item it should go back to by using that list of timestamps.

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

#385

Post by ugexe »

amichal wrote: post #372
jstimpfle wrote: post #352

Earlier quoted context omitted.

People are getting way to hung up about their commit history in most cases. If you're just experimenting, even "asdf" can be a totally fine commit message. And it shouldn't be hard to come up with something at least a little more descriptive in You can edit the history later when it's required by somebody else working on the code. Or you can just not care. 99% of the value of your git repo should be in the most recen…

Looking at other people's code I vastly prefer a feature branch with a summary name of the feature "new-checkout-flow" or whatever and then the commits as they where without squashing/rebasing. Mine tend to have quite a few commits cycling through: - Stub in [classes/models/etc] for checkout flow - Add basic test coverage - Fix my API for easier testing - Decouple foo from bar in new flow - New checkout flow mostly t…

On the other side of the coin I hate looking at git blame to find a bunch of now irrelevant stuff, like fixes to code that were only ever in your branch. I don’t generally care about the discoveries you made along the way (at least not in commit form) unless I’m doing the review for it to go in the main branch, and even then it’s more of a curiosity than anything particularly relevant to software quality.

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

#386

Post by Resinderate »

craigds wrote: post #189

In Sublime Text I actually use a quick Undo-then-Redo to navigate , of all things. I'll be typing some code and realise I need to check whether the imports at the top of the file are correct. So I'll Cmd+Up (go to the top of the file) and see that yes, they are correct. Now I have to get back to where I was. A quick Cmd+Z,Cmd+Shift+Z does the trick - Undo (takes me back to the code I was editing, and undoes some of i…

I do a similar thing, but I use "soft_undo" as it seems to include navigation jumps in it's stack so it's only one step. Think the default keybind is Cmd+U.

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

#387

Post by markdog12 »

xmodem wrote: post #292

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

Local History has saved me many times.

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

#388

Post by amichal »

ugexe wrote: post #385
amichal wrote: post #372

Earlier quoted context omitted.

Looking at other people's code I vastly prefer a feature branch with a summary name of the feature "new-checkout-flow" or whatever and then the commits as they where without squashing/rebasing. Mine tend to have quite a few commits cycling through: - Stub in [classes/models/etc] for checkout flow - Add basic test coverage - Fix my API for easier testing - Decouple foo from bar in new flow - New checkout flow mostly t…

On the other side of the coin I hate looking at git blame to find a bunch of now irrelevant stuff, like fixes to code that were only ever in your branch. I don’t generally care about the discoveries you made along the way (at least not in commit form) unless I’m doing the review for it to go in the main branch, and even then it’s more of a curiosity than anything particularly relevant to software quality.

I wanted "squash merge" to work for me to handle this. Full history in the feature branch for detailed git blaming and a single 1000-line merge commit in main with "New Checkout Flow" but i never fully groked getting it to work when you are merging upstream branches into you feature... You end up taking credit/blame for the upstream commits on main and I feel like you could overwrite the real history of that.

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

#389

Post by eithed »

My primary editor is VSCode, but I've got Sublime open as well. When making changes part way, I just cmd+x -> cmd+v to Sublime. This way if something doesn't work out I don't need to undo to whatever it was that was working.

If operating on multiple files I can have the snippets in the same tab, or different tabs in Sublime.

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

#390

Post by dmuth »

jonnycomputer wrote: post #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 com…

> When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew.

This is the comment I came here for. (see what I did there?)

I also sometimes keep multiple versions of the same line in comments, such as when I'm trying to a tricky regex work. For example, I might have code that looks like:

  # x = regex1 # Original line
  # x = regex2 # Doesn't work
  # x = regex3 # Nope
  # x = regex4 # Also nope
  x = regex5 # Currently testing this
That gives me the way to see which approaches I've tried while solving the problem, and ensures I don't actually use the same exact regex twice.

When I get a working solution, I comment out all but the line that works and commit that.

Post reply on HN