Every day. My team owns a 10+ year old system. None of the original authors are around any more. We're doing a massive migration of the system (several of them actually) and being able to go back and understand why the code was written the way it was is great. Earlier this week I needed to understand a very odd piece of code. It was making an rpc and if that threw an exception it was trying the same exception in the exception handler with different parameters. Looking back through the history turns out this was because the code used to do something different but during a migration was changed sick that the second set of parameters made no sense. One I understood that contact the fix was trivial and I felt safe making it
Ask HN: Do you ever truly use your revision history?
151–160 of 287 posts
Re: Ask HN: Do you ever truly use your revision history?
#152> they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.
Maybe the old guys didn't think there was a good reason to switch from SVN to git, if SVN had been working for them. It sounds like switching just because git became more popular. Of course if you're young, it's no big deal since you haven't been using SVN for decades, and what's the big deal with learning something new? But when you've been around the block a few times, sometimes there's needs to be a better reason…
Write down the nicknames. In 15 years git is ripe for next gen source control and then the same ppl will complain who are now advocating what is so hard on migrating
Re: Ask HN: Do you ever truly use your revision history?
#153Besides piling on with the others saying I use it a lot, I'll remind you that the old history can still be available, in a separate read-only repository, after you've moved on to a new tool. Not as convenient, but still available.
Some use cases are:
a) "Blame" tool, which produces a file version annotated line-by-line with who and when last changed that line, along with the commit message. "Who the f*&# did that s%$@#? Oh, it was me again..."
b) Searching the history of a file by keyword. Especially useful when something was deleted, and as such no longer exists in the source code, but you can find it by searching for the commit message. (knowing you can later do this gives you more confidence to actually delete things, instead of commenting them out or leaving them there in case they become necessary again)
c) "All I know about that feature is that Jenny implemented it before she left the company." Filter for Jenny's user tag.
d) "All I can find about that change is this old email saying it had just been done." Look at logs around email date.
Re: Ask HN: Do you ever truly use your revision history?
#154Yes, I often have to go back into commits from a year or two ago to discover the motivation for certain decisions.
https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
Re: Ask HN: Do you ever truly use your revision history?
#155Frequently. 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…
You can pipe through `less` and then search using `/`, no need to redirect into a file (and this way you don't have to wait for the history to be done dumping before you start your search, which can be a pain for very huge repos).
Re: Ask HN: Do you ever truly use your revision history?
#156Using them all the time:
- Looking at root causes of undocumented weird hacks and technical decisions
- Finding culprit, the one that causes a bug, in order to remind them to do better.
- Finding out someone underappreciated contributor
- Reverting changes.
- Cherry-picking changes.
A REMINDER: Revision history is great, but so is flexibility and velocity. You can always cut off history and use another tree (e.g. when moving from SVN to git), make a documentation about it, keep the SVN history as an archive and use git.
If a decision will boost velocity, flexibility, and sacrifice less valuable thing, you should do it, but make sure you will have a fallback.
In the end, flexibility is what you will need at every level (code, product, company) because the world around you (and requirements) always changes and you'll need flexiblity to be adaptive.
Re: Ask HN: Do you ever truly use your revision history?
#157Yes, absolutely, and failing to check the history of some changes can easily lead to re-opening closed bugs!
For example, we once had a customer-reported issue in an older version of our product (customers were complaining that an automation script for our product started lasting minutes where it previously took a few seconds). After some investigation, it turned out someone had deleted some code which excepted the scenario in the customer script from a timeout.
The commit removing the exception had a bug attached - the QA team had been complaining about the expected timeout not applying in some cases, and someone found the exception in the code and deleted it. They had no idea why the exception was there in the first place (according to the bug chat logs) and didn't bother to look back in history to see.
Funnily enough, looking back even further in history, we found that the exception had been introduced a few years prior, after a customer had complained that... some automation scripts were taking too long... the same automation scripts that we received in the new complaint, give or take a few years worth of additions.
Re: Ask HN: Do you ever truly use your revision history?
#158I 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.
We use reverts frequently enough that it's not an insurance option for us, it's just our normal workflow.
Re: Ask HN: Do you ever truly use your revision history?
#159Don’t ask the lawyers. They’ll want your document retention policy to apply to source code...
Re: Ask HN: Do you ever truly use your revision history?
#160> they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.
Maybe the old guys didn't think there was a good reason to switch from SVN to git, if SVN had been working for them. It sounds like switching just because git became more popular. Of course if you're young, it's no big deal since you haven't been using SVN for decades, and what's the big deal with learning something new? But when you've been around the block a few times, sometimes there's needs to be a better reason…
I used to be one of the "old guys" fighting against git because subversion is "good enough" and I didn't want to relearn a new tool. I finally had to learn git because a project I contributed to made the migration and I could no longer postpone it. I'd never, ever, go back.
At this point I'd go as far as saying that git is objectively superior to SVN because it does everything SVN can and then more. One caveat being potentially very large repositories and especially repositories containing sub-repositories, git was terrible at that and while it's improved over the past decade it's still a bit messy. Unfortunately in my experience these types of repositories are fairly common in proprietary codebase where people often don't hesitate to commit big binary files alongside the source code.
Still, I'd say that as a rule of thumb if a codebase is still in active use it's probably worth taking a week or so to migrate it to Git unless there's a very good reason not to.