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

I navigate through unfamiliar code almost daily, completely different projects and different authors. I use the blame feature a ton to understand in what context a method was added: by blaming it, I can usually see what other code was added at the same time, and its evolution.

I've used git-svn[0] to use git within svn, it's been working flawlessly in my case.

[0] https://git-scm.com/docs/git-svn

There is value in keeping track of who wrote each line of code. Even if it's quite old, you can still figure out the persons that originally worked on a particular project/module and ask them about it. If you reset history, this knowledge is lost.

"We won't switch from SVN to git due to the logistical challenge of migration".

It would be worth switching to git if the current technical costs outweighed the costs of the migration, yes.

I think there's more to it than just "we don't need all the history, just squash it and starting with git would be better" (or even "setup authors file, git svn fetch"), though.

We switched from SVN to Git about a year and a half ago. I often use the "annotate" feature in my editor to see the history of lines of code (to figure out who to talk to when I have questions), and I routinely run into the "initial commit" wall from when everything was squashed.

I wish that when the team had migrated from SVN to git, they had used a tool that would have preserved the history. It's very easy to do! I don't know why they didn't. They did it right before I joined the company so I never had an opportunity to show them how.

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 there. It's particularly useful when you remember that you did something, but forget how you did it.

In fact, I use git proactively this way, to store things in the version history that I might want to remember later. 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). The codebase remains unchanged, but what I just did is now there forever for future me to recover.

Such an approach only works if your system is small, but I like to work on small systems and prevent them from becoming large systems. There's a beneficial feedback loop here: as you get comfortable working with history, it gives you more confidence to delete things, helping to keep the system small.

I've also found this technique useful for solving the chronic problem with documentation: that it inevitably fails to get updated. When I write something about the code, I commit it and, as above, immediately revert the commit. Now it's permanently glued to the state of the code when I wrote it. When I read it in the future, I can do so alongside a diff of the code from then to now. This makes it easy to see what has changed in the meantime, in which case I can update the document and commit/revert it again.