Who wrote this piece of junk code? ... git blame ... oh ...
Ask HN: Do you ever truly use your revision history?
41–50 of 287 posts
Re: Ask HN: Do you ever truly use your revision history?
#42Our 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?
Re: Ask HN: Do you ever truly use your revision history?
#43If you find something wrong in the code, you can fix it with or without the context with which it was written.
If you fix it without context, you may not actually fix anything, and actually create a broken state. This may be a new bug or a regression.
If there's more context, you're less likely to fall into that trap.
Of course, this is all moot if there's decent documentation, but I've never been employed in a place that does. Everywhere requires reverse engineering / archeological expeditions to understand the mistakes of the past, before accepting them as necessary evils, or fixing them without breaking the side effects of the mistakes.
Re: Ask HN: Do you ever truly use your revision history?
#44I normally do not comment code unless it is a dangerous hack or a todo. Otherwise I make a small commit with a commit message explaining the why of the change. The git blame of our code base documents the why of almost every line and reviews are failed if they describe the what in a one line.
when we need to dig history of a line we git log -S
Re: Ask HN: Do you ever truly use your revision history?
#45Who wrote this piece of junk code? ... git blame ... oh ...
But seriously. I have seen many places just move the files from their old vcs and into git.
It is wrong to say you loose the history; you just have to go into old system to access it.
Also sometimes; you change from a monorepo approach to a repository pr. project approach and you want to tidy up in dead projects and irrelevant history while you do that.
Re: Ask HN: Do you ever truly use your revision history?
#46Yes, quite frequently. You are correct that it is often only the most recent history that really matters, but sometimes the most recent change happened years ago, so date-based cutoffs don't work.
When you do want to convert that SVN repository, use Reposurgeon (http://www.catb.org/~esr/reposurgeon/).
Re: Ask HN: Do you ever truly use your revision history?
#47An underrated feature is “blame” in the IDE. IntelliJ or Eclipse both support showing the last commit a line was changed in in the “gutter” of the code editor. Makes it easier to figure out how old a line of code is and (if the commit messages are any good) why it was introduced or changed.
>why it was introduced or changed.
"Fixed formatting"
Re: Ask HN: Do you ever truly use your revision history?
#48No not in 20 years except maybe 3-4 times
Shitty codebase and lack of tests defining business needs require it
Also Devs with headphones on not starting decisions ... That way when people leave no one know why it is the way it is.
Re: Ask HN: Do you ever truly use your revision history?
#49Yeah I've used it before.
Once I did a git blame on a file, found that the offending code had been committed nine years previous, and was able to figure out why the code was the way it was by looking at that nine year old commit and all the other code that had changed with that commit.
The nine year old context was super useful.
Re: Ask HN: Do you ever truly use your revision history?
#50Game industry uses source control _a lot_.
It’s an important communication tool. Also game companies tend not to have unit tests, but the culture is very much “don’t break _anything_, and don’t make the game worse,” so devs have to triple-check the intentions & effects of any code/script they touch, to be sure they understand what they’re changing and know it won’t introduce any unexpected changes. Timelapse view (Perforce’s version of git blame) is an essential tool for all departments, especially for anyone trying to figure out a bug.