I love reading through revision history but it's so, so easy to mess up given people and time.

We have a long history spread across several different (generations of) SCMs. I see each of the following quite often:

Most recent revisions (version A, code comments date code to the 90s):

- 2011-02-03: Migrate to git

- 2008-01-12: Migrate to SVN

- ~Fin~

Most recent revisions (version B):

- 2018-12-12: Split <X> out into own file

- ~Fin~

Most recent revisions (version C, sweet monorepo blogpost edition):

- 2019-10-01: Create monorepo for <Team/Superteam/Division>

- ~Fin~

---

It's hard to do transitions between SCMs (or between repos) right. For instance, when you follow the recommended steps for moving to a monorepo in git, the history is maintained but not shown in GitHub. It's so easy for well meaning people to destroy history or make it inaccessible for practical purposes when cleaning up dead code, reorganizing code, etc. Even if the history is still maintained (e.g. if there was a file rename in the same repository, you could use git log --follow, if you're trying to find when a particular snippet first came into existence, you can use git log -S<snippet>) but practically as soon as I run into one of the above, that's the end of the line.

I suspect that if the industry ever moves away from git in the next 5-20 years, it will be because there's another SCM that has this capability.

Just like DVCS "solved" branching and merging, following history through renames, splits, and other structural will make SCM 2x better.

I guess this is the place to ask: Anyone seen tools that make those jumps/skipping less important commits/... easier? Would be a good feature for a code exploration tool.

I once worked on a codebase where almost every mystery in the code could be traced back to a commit "Moving TIM one level down", and no further.

As in there was a terrible developer named TIM that caused all the problems in the code and the solution was to move him to the basement and assign him to non-coding tasks, so no one ever heard from him again?

It could be. I would have said that the reason was that the name of the software was the TIM, and at some point, the repo had been restructured so that the code for the main app was in a subdirectory rather than in the repo root, but that could easily have been a cover story.

EDIT Ah no, it couldn't have been that, because i met several of the developers who had caused all the problems in the code, and none of them were called Tim or in a basement.

Oh boy, library levels.

"How are we almost level 100 now? We're going to need an exemption soon!"

"We'd better go move around some orphaned, 20 year old C code to avoid triggering this well-meaning organizational policy!"

I was sure you and I must have worked at the same company. Alas, TIM isn't named TIM here though.

Whats' TIM?

Telecom Italia Mobile is a customer of ours, that's what I know as "TIM"

Indeed. I'm guessing I use the revision history several times a week. We have a complex code-base, often you'll want to check why something was written a certain way, so annotating and checking commits, and possibly the referenced JIRA issues gives that context.

You hit the nail on the head. The code review tool at my company links together all the commits that were in that code review, when there’s more than one package, I mean. It’s super helpful to look at what all was changed across packages and understand how the code base evolved.