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.
Ask HN: Do you ever truly use your revision history?
241–250 of 287 posts
Re: Ask HN: Do you ever truly use your revision history?
#242Re: Ask HN: Do you ever truly use your revision history?
#243The 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.
Re: Ask HN: Do you ever truly use your revision history?
#244Which 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?
#245Earlier 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?
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?
#246Earlier 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.
Re: Ask HN: Do you ever truly use your revision history?
#247Yes, 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…
Re: Ask HN: Do you ever truly use your revision history?
#248Frequently. 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…
Re: Ask HN: Do you ever truly use your revision history?
#249Earlier 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.
Re: Ask HN: Do you ever truly use your revision history?
#250In 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]