<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rca on vnykmshr</title><link>https://blog.vnykmshr.com/writing/tags/rca/</link><description>Recent content in Rca on vnykmshr</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 11 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.vnykmshr.com/writing/tags/rca/index.xml" rel="self" type="application/rss+xml"/><item><title>Git log as archaeology</title><link>https://blog.vnykmshr.com/writing/git-log-as-archaeology/</link><pubDate>Sat, 11 Apr 2026 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/git-log-as-archaeology/</guid><description>&lt;p&gt;The source file you&amp;rsquo;re looking at is a summary. The history is the full document. Most of the time you don&amp;rsquo;t care &amp;ndash; you&amp;rsquo;re working on the current shape of the code and the summary is enough. But sometimes the current shape stops answering.&lt;/p&gt;
&lt;p&gt;I reach for git history during RCAs, bug hunts, and questions the code can&amp;rsquo;t answer from its current form. Why is this file organised this way? Who introduced this assumption? When did this fallback stop being a fallback and start being the main path? The commit log knows. The current source doesn&amp;rsquo;t.&lt;/p&gt;</description></item></channel></rss>