<rss version="2.0">
  <channel>
    <title>Dotfiles on LLBBL Blog</title>
    <link>https://llbbl.blog/categories/dotfiles/</link>
    <description></description>
    
    <language>en</language>
    
    <lastBuildDate>Tue, 19 May 2026 10:00:00 -0500</lastBuildDate>
    
    <item>
      <title>A Dotfiles Manager That Snapshots Every Change</title>
      <link>https://llbbl.blog/2026/05/19/a-dotfiles-manager-that-snapshots.html</link>
      <pubDate>Tue, 19 May 2026 10:00:00 -0500</pubDate>
      
      <guid>http://llbbl.micro.blog/2026/05/19/a-dotfiles-manager-that-snapshots.html</guid>
      <description>&lt;p&gt;Managing dotfiles in 2026 is a solved problem in the same way that managing your own backups is a solved problem: there are five tools for it, all of them work, all of them require you to set up some plumbing first, and once you&amp;rsquo;re set up you still don&amp;rsquo;t have a great answer to &amp;ldquo;I just broke my shell config, get me back to yesterday.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;The conventional answer is some combination of: a git repo for your &lt;code&gt;~/.zshrc&lt;/code&gt; and friends, a symlink script (or &lt;code&gt;stow&lt;/code&gt;, or &lt;code&gt;chezmoi&lt;/code&gt;, or &lt;code&gt;yadm&lt;/code&gt;), and the discipline to remember to commit after every change. The setup is a one-time hassle. The &amp;ldquo;wait, what did I change?&amp;rdquo; recovery story is not great. And if you want to sync across machines, you&amp;rsquo;ve now got opinions about remote repos, SSH keys on a fresh box, and which order things have to happen in.&lt;/p&gt;
&lt;p&gt;I wanted something different, so not a configuration framework, but a record of every change to the files I care about, in a place I can roll back from, with the lowest possible setup cost.&lt;/p&gt;
&lt;p&gt;That&amp;rsquo;s what &lt;a href=&#34;https://github.com/llbbl/dotfiles-manager&#34;&gt;dfm&lt;/a&gt; is.&lt;/p&gt;
&lt;h2 id=&#34;what-it-does&#34;&gt;What It Does&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;dfm&lt;/code&gt; is a single static Go binary. You point it at the files you want to track (&lt;code&gt;~/.zshrc&lt;/code&gt;, anything under &lt;code&gt;~/.config/&lt;/code&gt;, whatever), and every time one of them changes it takes a content-addressed snapshot. The snapshots live on disk in &lt;code&gt;~/.local/share/dotfiles/backups/&lt;/code&gt;. A small state database (SQLite locally, or libSQL via Turso if you want cross-machine sync) records which file maps to which snapshot at which point in time.&lt;/p&gt;
&lt;p&gt;You can roll back. You can diff against an old snapshot. You can see when you last touched a file. And because every snapshot is content-addressed, you never re-store the same bytes twice — switching themes in &lt;code&gt;~/.zshrc&lt;/code&gt; ten times costs the size of two configs, not ten.&lt;/p&gt;
&lt;p&gt;The other half is the backup story. &lt;code&gt;dfm init&lt;/code&gt; walks you through cloning (or creating, via &lt;code&gt;gh&lt;/code&gt;) a private GitHub repo that mirrors your tracked files plus their history. The point isn&amp;rsquo;t to make you adopt a new git workflow. It&amp;rsquo;s that pulling your config onto a fresh machine should be one command, and recovering from &lt;code&gt;rm -rf&lt;/code&gt; should never have a &amp;ldquo;well, hopefully my last commit was recent&amp;rdquo; caveat.&lt;/p&gt;
&lt;h2 id=&#34;why-setup-is-the-hard-part&#34;&gt;Why Setup Is the Hard Part&lt;/h2&gt;
&lt;p&gt;The reason people don&amp;rsquo;t audit their dotfiles is the same reason people don&amp;rsquo;t back up their laptops: the setup is annoying, and the payoff is theoretical until it isn&amp;rsquo;t.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;dfm init&lt;/code&gt; is a six-step interactive wizard. It detects a &lt;code&gt;TURSO_DATABASE_URL&lt;/code&gt; env var if you&amp;rsquo;ve got one, offers sensible defaults for everything else, lets you opt in to tracking &lt;code&gt;~/.zshrc&lt;/code&gt; immediately, and writes a single config file with the right permissions. Re-run it on an existing config and it pre-fills every prompt with your current value, so the cost of changing your mind later is also low. &lt;code&gt;--yes&lt;/code&gt; accepts every default for scripted setup.&lt;/p&gt;
&lt;p&gt;If that sounds boring, that&amp;rsquo;s the point. Boring is what makes a tool actually get used.&lt;/p&gt;
&lt;h2 id=&#34;the-ai-bit&#34;&gt;The AI Bit&lt;/h2&gt;
&lt;p&gt;There&amp;rsquo;s an optional AI integration. &lt;code&gt;dfm suggest &amp;lt;file&amp;gt;&lt;/code&gt; asks a local AI CLI (Claude Code by default, configurable) to propose an improvement to one of your tracked files, returns the proposal as a unified diff, and stores it as a pending suggestion. &lt;code&gt;dfm apply &amp;lt;id&amp;gt;&lt;/code&gt; reviews the diff and applies it, with a fresh snapshot first, so you can roll back if the suggestion turns out to be wrong.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;m exited to try this feature out, because I&amp;rsquo;m sure there is something i&amp;quot;m doing wrong. The &amp;ldquo;Look at my &lt;code&gt;~/.zshrc&lt;/code&gt; and tell me what I could clean up&amp;rdquo; is useful feature that doesn&amp;rsquo;t require me copy and pasting or granting read or write access to my entire home directory.&lt;/p&gt;
&lt;h2 id=&#34;where-to-get-it&#34;&gt;Where to Get It&lt;/h2&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/llbbl/dotfiles-manager&#34;&gt;github.com/llbbl/dotfiles-manager&lt;/a&gt;. Pre-built binaries for darwin and linux on arm64/amd64. Current version, as of writing, is v1.4.0.&lt;/p&gt;
&lt;p&gt;If you&amp;rsquo;ve been meaning to actually back up your dotfiles and the friction has stopped you, this is the post where I tell you the friction is solvable.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at &lt;a href=&#34;https://micro.blog/llbbl?remote_follow=1&#34;&gt;@logan@llbbl.blog&lt;/a&gt;.&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>