Ask HN: Do you ever truly use your revision history?
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.<p>One of my favorite tricks is to make a file out of all the changes in the history:<p><pre><code>  git log -p &gt; bigass
</code></pre>
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&#x27;s a lot of knowledge in there. It&#x27;s particularly useful when you remember that you did something, but forget how you did it.<p>In fact, I use git proactively this way, to store things in the version history that I might want to remember later. 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&#x27;t want to commit to the codebase—I&#x27;ll add it as a commit and then immediately revert the commit (i.e. make a new commit that deletes what I just added). The codebase remains unchanged, but what I just did is now there forever for future me to recover.<p>Such an approach only works if your system is small, but I like to work on small systems and prevent them from becoming large systems. There&#x27;s a beneficial feedback loop here: as you get comfortable working with history, it gives you more confidence to delete things, helping to keep the system small.<p>I&#x27;ve also found this technique useful for solving the chronic problem with documentation: that it inevitably fails to get updated. When I write something about the code, I commit it and, as above, immediately revert the commit. Now it&#x27;s permanently glued to the state of the code when I wrote it. When I read it in the future, I can do so alongside a diff of the code from then to now. This makes it easy to see what has changed in the meantime, in which case I can update the document and commit&#x2F;revert it again.