Live data from Hacker News

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

news.ycombinator.com

1–10 of 287 posts

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

#1
Source control gives you a full history of every change that's ever been made to your codebase since its beginning. At my current company they place a huge value on that history, so much so that they haven't transitioned from SVN to git solely because of the logistical challenge of migrating 30 years of commits.

Obviously the write-only paradigm is useful when reconciling changes with others and when reverting recent, broken changes or recovering accidentally-deleted work. But to me, it seems like there's diminishing value the further back you go. I can't imagine getting much value from trawling through two-year-old commits, much less twenty-year-old commits.

So I ask: at your company and in your experience, do you get value from source-control-arachaeology? And if so, what does that look like in your case?

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

#3
For recent commits, it is useful for figuring out causes of bugs that have been brought up recently by checking out to an earlier commit until it goes away.

As for commits that are over 2 years old, they still serve a purpose. For a legacy app that I worked on, I had `git blame` ran on every line (vim and vscode both have support), and I was able to see who worked on a block of code last. Sometimes, those developers are still there and available to ask questions which has helped me greatly.

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

#4
Yes, we get a lot of value out of version history. It is a good tool to evaluate existing code. We also have experience with leaving the history behind from migrating to git.

Our case was a tooling policy issue but it should be possible to migrate from SVN to git and keep the change history. You should investigate this option.

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

#5
I very rarely go back more than a month or so. Very occasionally I have gone back 10 years but only for the weirdest problems and to get a sense of what the person was thinking when they added that code. I think I could live with just 6 months of history, and in most cases 30 days and never have a problem.

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

#7
I did work for a company where they had a few important vendors who would run legacy versions of their software and demand a bugfix for that version. They did this only once or twice a year, but being able to reproduce and patch old versions was enough to get some clients to shell out absurd amounts of money. These companies were swimming in cash and didn't like to learn anything new. Needing old commits is rare, but important.

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

#8
Yes! My company has source that is 20-30 years old, sometimes just going through the history to see who has committed on it and checking if that person is still in the company is already a win, other times there's a code review link or a ticket system link that gives possibly more context to why something was made.

(Granted code review systems and ticket systems change overtime)

Git blame on gitlab is also a good way of getting context of why something is there to begin with.

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

#9
I’m a QA engineer and I go back pretty frequently so that I can see when a issue popped up and what might have caused it. It’s super useful for root cause analysis on bugs. also I use it to troubleshoot legacy versions for customers. Although I see less of that since I work on a saas product now.

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

#10
With the exception of rare uses of git blame (hate that name) to figure out who made a change so I can ask them if they happen to remember about it (and if it was more than a year so my expectation is “I don’t remember” which is fair enough)... virtually never. I don’t care if my git history is “clean” or “dirty” (if you never use a tool to make a visual of the branches then you’ll probably never notice or care).

We put Jira ticket IDs in our commits and sometimes that’s useful. But the value tends to be in the content of the tickets as much as the commits.

If we decided to squash everything more than a year or two old into a single commit I doubt it would affect us very much in practice.

Post reply on HN