I use it quite a bit for various reasons. But I think I get the most value from just knowing it's there. I can plow ahead with anything, try anything, experiment, it doesn't matter. I know that my previous history is there waiting for me if the plunge I just took doesn't pay off.
Ask HN: Do you ever truly use your revision history?
181–190 of 287 posts
Re: Ask HN: Do you ever truly use your revision history?
#182Yes. Nearly everyday. And the overhead of migration is nearly fixed no matter the size of the history. The expensive part is writing the script to do the export/import.
Re: Ask HN: Do you ever truly use your revision history?
#183I'm enjoying all the comments here! Thank you OP for demonstrating the effective use of Cunningham's law: "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
[deleted]
Re: Ask HN: Do you ever truly use your revision history?
#184Frequently. 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…
> For example, if I write exploratory code to test out a feature or throwaway code to do some analysis—anything I might want to use again, but don't want to commit to the codebase—I'll add it as a commit and then immediately revert the commit (i.e. make a new commit that deletes what I just added). Why not use a named stash for something like this? It'll keep your history cleaner, and you can always find the stash by…
Can stashes be pushed to a remote repo?
Re: Ask HN: Do you ever truly use your revision history?
#185Earlier 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.
I personally think of version control history as like a sedimentation layering of documentation that "updates" itself in the process of doing the work -- like the desk that looks messy, but by picking up and using papers, the most important stuff is on top. "Real" documentation can be clearer, but it must be maintained manually, and cleared out regularly. VCS kinda handles this with less process weight.
The right tactic is def a mix of both though, so I think I'm in agreement with you :)
Re: Ask HN: Do you ever truly use your revision history?
#186I'm working on a 15-year old codebase, and I was here from the beginning.
I use 'blame' daily to make sense of code - why it was added, for what project, for what feature, to fix what bug, and who added it.
It's priceless, and I'm putting off stuff like getting rid of stupid homegrown types instead of standard ones, using clang-format consistently, and migrating to a small, newer probably faster repository format because I don't want to use history.
I realize the value of this history is smaller for newcomers to the team.
(And Subversion and it's bigger, expensive brother Perforce still make sense for game development - when you don't really want to go wild with branches or remote work, and when you need multi-terabyte-sized repositories and multi-gigabyte single commits.)
Re: Ask HN: Do you ever truly use your revision history?
#187With the exception of rare uses of git blame (hate that name) to figure out who made a change so I can ask them if they happen to remember about it (and if it was more than a year so my expectation is “I don’t remember” which is fair enough)... virtually never. I don’t care if my git history is “clean” or “dirty” (if you never use a tool to make a visual of the branches then you’ll probably never notice or care). We…
> With the exception of rare uses of git blame (hate that name)
I do too, so it's worth noting that you don't have to call it that. I think it was a mistake for Subversion to introduce blame as a cute alias for annotate, but its successors (at least Mercurial and Git) have at least retained annotate as an alternative. So you can git annotate to your heart's content and never blame anyone at all.
Re: Ask HN: Do you ever truly use your revision history?
#188I have never needed it so far, although I have it in case it is useful to me or someone else in future.
Re: Ask HN: Do you ever truly use your revision history?
#189Postmortems.
Re: Ask HN: Do you ever truly use your revision history?
#190Yes. I do git blame/annotate every day on a code base that is over 20 years, 100k commits. I migrated it myself to svn in 2007 without history which I regret because a lot of changes now look like they are from the initial svn commit in 2007 when in reality it had an older history. For that reason I spent a lot of care when migrating to git to include all history but also trim away some dead parts and mistaken commits from the past. Getting a chance to clean up history is great. Migrating an svn repo to git was definitely worth it. It was not a huge logistical challenge as there are great tools for it. The hardest part was finding which tool to use.
The most common use case for archaeology is to find who made a particular source line change 10 years ago and just ask them something. I often find it’s my own code...
People usually remember at least vaguely why they wrote the code even 10 years ago.