Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 287 posts

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

#51

Post by hinkley »

bacon_waffle wrote: post #24

We just switched from Perforce to git at work, and about the first 2/3 of a project I work on got squashed together. It took me less than a week to bump in to that "initial commit" when trying to figure out why a bit of code is the way it is. "git blame" (or the p4 equivalent) is my usual archaeologic tool in this context, but "git bisect" has been very helpful in others. For the first, it should be easy to look at y…

I spent a couple months experimenting with p4git to make sure we got a real history imported. They didn’t get every repository right and I made them redo a few, did a few others over again myself.

But lately I’ve been delving into some of the early architectural changes, trying to figure out why a bunch of things get loaded and seemingly never used/only used once... and sure enough someone did some sort of single commit repository split or bull transfer into p4 in the first place... so I have no clues why.

And yes, I use commit history all the time. Fewer secondary bugs from bug fixes. Fewer lines changed per fix, and fixing bugs nobody else can figure out. Started when someone was furious that a bug had been reintroduced twice. Two devs were alternating fixes for two bugs that caused each other. Good times.

If anything I want more commit history. I want to be able to go back and add notes to commits for posterity, or at least for myself in six months when I have forgotten because I haven’t looked at this module once in that time.

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

#52

Post by hinkley »

sleepychu wrote: post #30
bacon_waffle wrote: post #24

We just switched from Perforce to git at work, and about the first 2/3 of a project I work on got squashed together. It took me less than a week to bump in to that "initial commit" when trying to figure out why a bit of code is the way it is. "git blame" (or the p4 equivalent) is my usual archaeologic tool in this context, but "git bisect" has been very helpful in others. For the first, it should be easy to look at y…

+1 for git bisect, criminally underrated!

Reverts that get to master can royally screw up git bisect.

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

#54

Post by DecoPerson »

DecoPerson wrote: post #50

Game 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 (Pe…

I actually read the description (we call it the “take message”) of every changelist submitted to our main dev branch. It’s a great way to learn, and maintain awareness of anything that may be relevant to my duties. Unfortunately it’s now in the hundreds per day (team is growing), so it becomes hard to actually process the info.

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

#55

Post by hinkley »

The p4 import tool can do incrementals so I would be surprised if the sun one doesn’t as well.

You fiddle with it until you get it working the way you like, then you do an import in the background or overnight. It takes as long as it takes but you don’t care. When it’s time to make the transition you aren’t importing the whole thing, just the past week. The older stuff has already been transferred over.

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

#56

Post by hinkley »

yardstick wrote: post #36

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…

You should have rewritten history. It’s less invasive than doing it in svn.

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

#57

Post by redis_mlc »

onion2k wrote: post #27
redis_mlc wrote: post #6

As a DBA, I use git blame to see who wrote slow queries. Then I assign a jira to them. :)

If your ticket explains why the query is slow and suggests an alternative that would be faster I'd welcome that. If anything, I would expect a good DBA to do that.

Well, that level of TLC isn't going to happen when ...

- I'm doing batches of 50 at a time (quarterly review)

- the SQL doesn't make any sense in the first place.

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

#59

Post by DanielBMarkham »

dang wrote: 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 flexible tools can be used perhaps in ways not anticipated by their creators or the majority of their users.

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

#60

Post by hinkley »

onei wrote: post #32
thih9 wrote: post #20

I use it to find more detail about a particular line. Often knowing when something was added, who added it and what was the commit message helps me understand the reasoning behind some particularly weird or legacy code. In some projects this can lead you to a pull request link, with even more context.

I'd second that. I've also used old revisions to try and figure out when a particular bug I've found was introduced too. Depending on how long it's been there can help you assign a priority, e.g. minor bug has existed for 10 years without anyone noticing is probably not something you have to fix right now. The opposite of that is a nasty bug has existed for 10 years until some data structures or control flow changed…

First git project, had a guy who loved deflecting, hated git, and had a habit of fucking up merges. Let’s call him Steve.

Some code got broken and Steve immediately throws Jim under the bus. I look at the commit history, and sure enough git blame shows Jim broke it. Except... there was one little problem: I was the one who signed off on that code. I was specifically looking for this exact class of bug before I approved it, and was pleasantly surprised to see that the author had already anticipated this problem.

So what the hell happened?

Steve happened. Steve fucked up (another) three way merge and I didn’t catch it this time. I found the original commit hash and sure enough the code was correct. So then I showed Steve, again, what I call a Five Way Merge (3 way merge, then resolve again against both parents) and made it pretty clear this was no longer a strong suggestion and now a demand that he use this method to do merges.

Post reply on HN