Live data from Hacker News

Ask HN: Do you ever truly use your revision history?

news.ycombinator.com

111–120 of 287 posts

Re: Ask HN: Do you ever truly use your revision history?

#111
It varies. There was a mostly complete PKIX path resolver I worked on a year or so back, that turned out at the time to be unnecessary so I diteched it. Fast forward a year and it became useful and saved a week or more of work. But that was only useful because I knew it was there, and it was still relatviely current.

What benefit you can get from 30 years of commits I'm not sure.

By the way - it looks to be possible to migrate history from SVN to Git, so if your company needs that, maybe start there , by creating a local git repo with intact history and showing it to them.

Re: Ask HN: Do you ever truly use your revision history?

#112
post #96

All the time! Two weeks ago I found something in a critical library at work (that ~every single C++ binary we run depends on: our main implementation of our custom threads' executor API) that made no sense. I couldn't understand why a variable was being rounded before being passed down to a lower layer, in a way that introduced an average 0.5 Ms of latency to many operations (I estimate that at peak, just one of the…

Seconded heartily: git bisect is one of those tools I use very infrequently but when I do, it is a lifesaver.

Re: Ask HN: Do you ever truly use your revision history?

#113
all.. the... time

if you have never experienced the raw power of "git bisect" when trying to hunt down a bug, you're missing out.

using git bisect can literally save your life in terms of stress. I think it one of THE most important tools in git that developers can learn. it shows exactly why we should commit small and commit often.

https://www.youtube.com/watch?v=REaowJ8JSfw

Re: Ask HN: Do you ever truly use your revision history?

#115
post #19

Frequently. Just this evening I was looking in the HN repository for the last version of the code that pg wrote, to remind myself how he used to do something. One of my favorite tricks is to make a file out of all the changes in the history: git log -p > bigass and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in the…

> For example, if I write exploratory code to test out a feature or throwaway code to do some analysis—anything I might want to use again, but don't want to commit to the codebase—I'll add it as a commit and then immediately revert the commit (i.e. make a new commit that deletes what I just added).

Why not use a named stash for something like this? It'll keep your history cleaner, and you can always find the stash by name later.

Re: Ask HN: Do you ever truly use your revision history?

#116
Before using git, my code/comment ratio was ~1/2 as there were many things that "may be useful in the future" (usually they weren't)/

And yes, once in a blue moon there is a change that breaks something, I need to go back and recover some old code. Much more often - I need to see how it worked before.

Plus, let's second the psychological benefit. I don't need to worry or think twice before changing code.

Re: Ask HN: Do you ever truly use your revision history?

#117
Yes! So, from my experience it's invaluable to: See why things were done like that. My best usage so far of it was to add a #number at the end of the commit message where number is a trello card id. Then you can go back to the discussion and card that originated that change. You can see all the context of why something was done like that.

This becomes very valuable when maintaining projects that will be running for years, and prevents you from undoing things or going back to doing the same mistakes

Re: Ask HN: Do you ever truly use your revision history?

#118
post #84

I think there's some indirect psychological value that shouldn't be underestimated. People have a tendency to comment out unused code "in case they still need it". Or not delete unused stuff, because who knows what. I have the feeling that I'm much more inclined to just delete a bunch of code lines that "I might still need in some situation" if I know there's version control. Because even if it's unlikely, "I can get…

Version control is like an out-of-the-money option, or like a home insurance policy. And just like with an OTM option in capital markets or with a home insurance - the point isn't that you know you'll use it. The point is that you can, if need be, which allows you to take more risk (in your example - delete some code). It's not just psychological, it can be explained quite easily in terms of risk management.

Re: Ask HN: Do you ever truly use your revision history?

#119
I’ve inherited code bases that migrated from SVN to Git without converting and bringing over the old revisions. This has resulted in a number of times where I hit a cliff when trying to identify when a piece of code was changed as everything points back to the initial “SVN import” commit. Couple that with the original SVN repository being unavailable (either lost or just not worth the trouble of finding in 10 years worth of offline backups) and I would say yes, having your source control under one system with all of its history is ideal.
Post reply on HN