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

Git annotate is a fantastic tool, even if the developers aren't great contributors.

A lot of developers do not write good statements. They don't even link to a ticket. But you get to know those developers real quick when you're doing spelunking using annotate. And developers who don't write good commits probably didn't leave any other documentation behind of use.

I've used this to illuminate "technical debt" from a different perspective. If you take a critical code path, find the important commits for critical logic, and then just show the "context" you're left with, you'll often be able to say "this is why your quality sucks" in a real concrete way.

Managers love proof, and showing them what little context you have for critical areas can be a very different way of looking at the quality of their systems. Otherwise, I've often seen a LOT of overconfidence largely because "we have automation in place".

Yes, responding to the title. In particular in my rich web application if I am in the process of merging & deploying the branch to the production environment, sometimes the automated tests fail and I use a bisect to narrow down the offending commit. Having good commit messages in general helps with debugging in this scenario.

I’m surprised you haven’t found excellent tools to migrate from SVN to Git, considering how popular these VCS systems are.

I once worked in a company whose source tree originally predated version control. There I found an entire module that appeared to be dead code and I wanted to determine how it became dead. I did a bisect and landed on an 8 year commit that was the very first commit in the version-controlled tree. Yikes. So I guess I’ll never know how that module became dead.

Well, the Unreal Engine is 22 years old. I doubt the current incarnation is free of legacy code.

It’s not every day but it’s extremely useful when you need it. I’ve used that history to find context for when someone made an otherwise unexplained change - tickets; names of people, projects or departments; the commits immediately before or after; etc. can all be really handy for learning why something works a specific way. (“Why are we pinned on this ancient version? Oh, that server was decommissioned years ago - we can drop it “)

In your specific example, git-svn works really well for maintaining that history including authorship. I have a few projects which predate Git existing and it’s been quite usable for history. You can’t direct link to a commit ID but Git searches are very fast (we’re not on 20 year old hardware) and you shouldn’t be doing this many times a day.

It only took a day (actually a few partial days) to make a script that could migrate projects from CVS to Git. The importer we used kept all the comment history and even converted multiple commits at the same time with the same comment into multi-file commits. So no need to go looking through the old VCS for the old stuff.