Live data from Hacker News

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

news.ycombinator.com

71–80 of 287 posts

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

#71
All the time. If I'm reading code and think "why on earth is this here?" the first thing I do is hit the git blame page on GitHub.

If a project has a clean commit history, this instantly gives me extra context and hopefully even links me to an issue thread explaining what was being solved.

In older code bases this is invaluable - I often find myself looking at history from five years ago or more.

It's also great for my own projects. Even if I wrote the code six months ago there's still a strong chance I won't fully remember the context for the change.

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

#72
post #19

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 the…

This is good. I'm stealing it. It's using git as sort of a super-brain, helping you remember stuff you wouldn't otherwise. It's how I use gmail. Instead of shooting for inbox zero, I just leave anything in there that I might want to remember later and delete the rest. Then, many times years later, I can search through looking for important correspondence. Both of these stories are good examples of how simple but flex…

Inbox zero isn’t deleting everything, it’s archiving those that are done so they aren’t in your immediate inbox.

What you’re doing sounds compatible with that.

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

#73
Revision history is essential for traceability in safety critical work. The entire history with name and timestamps can show both who introduced a problem, but also gives context for how a more subtle architectural issue got baked in slowly over time by multiple people. It can then be fixed, and possibly the process can be updated to help avoid such hard to spot issues in the future.

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

#74

> 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.

It may well be the reason. I don't know the parent commenter but speaking from my own experience I recently tried to migrate a legacy code base from svn to git and the common tools all failed for me. One of them ran for ~72 hours before falling over for "reasons".

That was only ~6 years of commit history too. I could imagine 30 years is a whole extra logistical challenge. Not to mention making sure the whole developer base is aware of the change, prepared for it and willing to either update documentation where it refers to revision numbers or write some instructions on how to find a new commit reference from an old revision number.

The tag model is also different between svn and git.

It's not out of ignorance that the switch can be difficult, we've had some projects on git for years and we're comfortable with it.

Just because you've switched easily from svn to git doesn't mean everyone has the same experience.

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

#76
It's very simple to migrate even really old Subversion repos to git. If they claim it is an insurmountable logistical challenge, then they don't know what they are talking about.

Yes, there is diminishing value in old commits, but they are far from worthless! Never ever destroy the commit history. Doing that is imho, a cardinal sin.

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

#77
At least once a month, when modifying some critical piece of code - git blame is the easiest way to find reasons for non-obvious lines of code.

BTW: if you sometimes move code around between two git repos (from multirepo to monorepo for example), I wrote a script to move a subfolder between the two and keep history:

https://github.com/jakub-g/git-move-folder-between-repos-kee...

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

#78
post #42

Our codebase is around 20 years old and was in CVS, then SVN, then git. Then several years after git, a new git repo without any history due to poor use of the first git repo (someone added binaries, bloated the repo to GBs instead of maybe 200-300MB, which made git export horridly slow). In all the steps we preserved the commit history, except for the final git->git. However also when we moved from SVN to git we kep…

>Then several years after git, a new git repo without any history due to poor use of the first git repo (someone added binaries, bloated the repo to GBs instead of maybe 200-300MB, which made git export horridly slow). Considering you already needed to freeze work, couldn't you have removed/ammended the commits affecting those files and the force pushed including the history with a smaller repo?

Thought about it, but for external security audit purposes we aren’t allowed to rewrite history.

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

#80
post #19

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 the…

can anyone truly ever gitlog bigass?
Post reply on HN