Live data from Hacker News

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

news.ycombinator.com

241–250 of 287 posts

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

#241

Earlier quoted context omitted.

Chestertons Fence, to put a name to the phenomenon. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

How so? In GP's case, they found that the "fence" really was no longer needed: > Someone cleaned up the lower level library in 2016 or so, but the rounding remained in the upper layer. This is like the opposite of a Chesterton fence, where the reason it was put up no longer exists, so it's totally safe to remove it.

The point of Chesterton's fence isn't that the fence is necessarily still useful, it's that being ignorant of the usefulness of a thing isn't equivalent to knowing that it's useless.

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

#243
post #162
post #104

The more public and more developers it has, the more I use it. The project where I use it the most is Linux kernel. It's also probably because there's a strong requirement to actually write useful commit descirptions. But if changes come from so many developers, it's very useful to catch up on news, what's coming to the next kernel release, what changed in what driver or subsystem, what might have caused the regressi…

Yea, the only times where I don't use it is when I'm working solo on small projects. Then the dirty tricks like duplicating files into `.bak` or `-ver3`, comment-out unused code for potential reuse later, etc, are actually more time-efficient at least for a non-git wizard like me. It's invaluable in larger projects, even as small as 2 persons.

I mean, I still use version control for pretty much everything. I just don't look at history all that much or try to write very careful commit messages for the small personal projects.

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

#244
This kind of depends. Many years ago we migrated an SVN project to git(largely because of my constant complaining about SVN which I truly hate) but we didn't bother with keeping the history. We simply kept the SVN repo for another ~2 years if we ever wanted to check something. At a certain point when we felt like the project was stable, we got rid of it. I've gone to looking back to where something came from on a number of occasions so I would say it is valuable.

Which applies to any project on which a number of people is working on. Especially when there is a bug, git blame is a life savior. Which potentially has a lot to do with me being annoyingly pedantic about commit messages and branches. I did however had the "pleasure" of working with a guy who's branches were commonly called "bugfix102015" and commit messages along the lines of "fix some bug". In such cases there is not much you can do when shit hits the fan.

For my very personal projects - hardly. Much like you, if something has been done 2 years ago, chances are it's working fine as it is, or you are not using it at all. So for personal projects, digging years back is something I don't ever recall doing.

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

#245
post #194

Earlier quoted context omitted.

It's both better and worse than its ever been. There's an awareness and discussion about "sustainable" development practices, but a large portion of our workforce had to leave for stress reasons last year, on a project that is saying "sustainable development" the loudest.. so while it feels like lip service, at least there's an awareness at some level. (also, gamers are more entitled than ever, so we're always runnin…

I’m making a game of my own right now and am curious about the larger industry - is it common for AAA companies to claim ownership over all ip you create, even outside work? (My last job did this) - How would one find part time or short term contract work in the games industry?

> - is it common for AAA companies to claim ownership over all ip you create, even outside work?

Yes. This is super common. Depending on the company you can make some kind of agreement. Most agreements are based on income (so if you make a lot of income you need to renegotiate, something 10% your yearly salary or something).

> - How would one find part time or short term contract work in the games industry?

If you’re an artist, I guess this is easier because those are contracted out positions. But for others it’s unlikely the company will hire you for part time work. They seem to want everyone giving 111%, a part timer might be useful but could cause blocking issues.

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

#246
post #227

Earlier quoted context omitted.

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.

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?

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

#247
post #212

Yes, but maybe not in the way that you're thinking. The scenario isn't "I'm gonna go browse the changes that were made in March of 1994", instead it's trying to solve a specific mystery. You see some code that doesn't make much sense, so you look at git blame to find the commit where it was written. Look at the full change, read the commit message, and now you've got some more context. Often this is enough to underst…

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.

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

#248
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…

I’m stealing this too! I often try to persist exploratory history as separate remote branches, but for some reason a lot of the devs I’ve worked with are very adamant about deleting any and all “unneeded” branches, and I end up appending such branch names with a “-dont-delete”, but that starts to get abit passive aggressive. Now I can just do this and nobody needs to know

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

#249

Earlier quoted context omitted.

Code history is documentation. There are lots of different kinds of documentation: code API level, module level, system level, tutorials, even books in some cases. Revision history is just another one of those levels, and I believe it is the best at capturing the "why"s of systems rather than just the "what"s.

I agree code history can be used as a form of documentation, but in cases like this looking through years of code to find the decisions/reasons leading to a particular design seems like inefficient communication. It seems like "real" documentation with a few sentences explaining directly would be more suitable.

It's because "your commit needs to link to something in the bug tracker" is pretty easy for code review to enforce, but I have never seen an org manage to indefinitely keep an accurate as-built design doc beyond the code itself. You can convince people to write new aspirational design docs for intended major changes, but after approval those never get updated to reflect what really got built, and lots of small bugfixes don't get one at all.

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

#250
I've done it both ways. I've had to partition a years old code base, keeping an old SVN repo up to a certain date, then using my own limited git-svn skill to promote some recent months to git, to establish a git repo for use from there forward. At another company we had a magician who ported maybe 10 years of SVN history to git over a weekend, and we were able to abandon the SVN repo.

In the first case, I don't recall ever needing to go back into the old SVN repo, spelunking for "how we used to do it". But the capability was there, with the minor hassle of not having a single repository to search. The git repo, with some minimal recentish history, soon became the authoritative source, and we never looked back.

[edited to clarify the partitioning of the first codebase]

Post reply on HN