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

241–250 of 424 posts

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

#241

Post by sixstringtheory »

nilsbunger wrote: post #169
lilyball wrote: post #168

In Git you don’t have to actually commit, you can use the staging area. It’s something I do rather often. I’m going to make a non-trivial change and I’m not sure if it’s the right approach, so I `git add -A` first, make my change, and then `git diff —-cached` to review it. This is especially useful when doing things like running formatting tools, so I can see what the tool just did. And it doesn’t require making any…

Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push. Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together

You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)

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

#242

Post by xyzzy_plugh »

ramraj07 wrote: post #40
nexthash wrote: post #19

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…

As some other comments suggest, vim is the gift that keeps on giving. I'm not going to try and convince you to use it -- do whatever you want.

But for me, every little thing I learn in vim pays off... a thousand times? Macros alone have probably saved me a cumulative few hundred hours. And with every other little thing I learn, compounds with this effect. I write macros much better than I did five years ago, but I still surely have tons of stuff to learn. No IDE will ever compete because vim is just four keystrokes away at any time, no matter where my terminal is.

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

#243

Post by strken »

OskarS wrote: post #213
interfixus wrote: post #212

Earlier quoted context omitted.

This is the one thing above all else which has kept me off Go. Tentatively comment out a line or two and the whole compilation process may come crashing down because now you have a declared but unused variable, and mere warnings apparently aren't Gestapo enough in this particular universe. You then find and comment out the offending declaration, only for the compilation to die in flames again because now you referenc…

Are unused variables really compiler errors in Go? That does seem very harsh, and very counter productive while developing. -Werror is all well and good, but while I’m in the middle of writing the code, it’s a bit much.

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.

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

#244

Post by xyzzy_plugh »

sixstringtheory wrote: post #241
nilsbunger wrote: post #169

Earlier quoted context omitted.

Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push. Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together

You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)

Yes. I usually maintain a hefty stack of commits where the top ~5 are experimental WIP nonsense for me to either clean up to or discard, the next ~10 might be code out for review. But in between pushes to remotes, every session of changes turns into a slew of fixups and I'm often rebasing a stack of 30+ commits, massaged into 2-3 change sets.

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

#245

Post by jack_riminton »

hazeii wrote: post #203
throwaway744678 wrote: post #199

Earlier quoted context omitted.

In C, you can wrap the 'commented' code with #if 0 ... #endif

Or indeed if rewriting a block of code: #if 1 ....new code... #else ....old code... #endif Esp. for tricky stuff, it's then possible to just flip the 1/0 to easily test/compare/profile the new/old code. Some IDE's will even work out which block of code to colour and which to dim.

Why have I never thought of that?

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

#246

Post by jack_riminton »

WesleyJohnson wrote: post #153

Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory." Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming…

"Sounds like trial and error"

Isn't that what coding is?

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

#247

Post by dustymcp »

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…

I do the exact same i was thinking this article was silly..

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

#248

Post by tluyben2 »

mosselman wrote: post #230
tluyben2 wrote: post #192

Earlier quoted context omitted.

> the wrong way is not constructive. Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It b…

It sounds like you are a software engineer. My advise for you being confronted with these metrics is to look around a bit at other workplaces. I am not saying that you should quit, but it doesn't need to be this way.

Well, I don't have that issue, but I know quite a lot of people whose workplace changed to that. I would refuse to work like that, not to mention that keyboard logging etc is not allowed here in the workplace.

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

#249

Post by unnouinceput »

Oh, this is a neat idea. I can easily do this for everything using hooks. Just a minimal GUI, target window to hook into (handle to it) and then every keystroke into its own. Combine this with a multiple view/diff and you have a good version control on the fly.

Be right back, I'll go implement it right away.

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

#250

Post by doix »

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…

> Most cool of all is that vim can persist the undo history. I don't know how common that is among editors, but in vim you can go to a file you haven't opened in years and undo it all the way to its beginning.

I absolutely love this feature. I regularly open a file and undo/redo to figure out where I was editing last.

Post reply on HN