[HN Gopher] Show HN: Unfucked - version every change between com...
___________________________________________________________________
Show HN: Unfucked - version every change between commits - local-
first
I built _unf_ after I pasted a prompt into the wrong agent terminal
and it overwrote hours of hand-edits across a handful of files. Git
couldn 't help because I hadn't finished/committed my in progress
work. I wanted something that recorded every save automatically so
I could rewind to any point in time. I wanted to make it difficult
for an agent to permanently screw anything up, even with an errant
_rm -rf_ _unf_ is a background daemon that watches directories
you choose (via CLI) and snapshots every text file on save. It
stores file contents in an object store, tracks metadata in SQLite,
and gives you a CLI to query and restore any version. The install
includes a UI, as well to explore the history through time. The
tool skips binaries and respects `.gitignore` if one exists. The
interface borrows from git so it should feel familiar: _unf log_ ,
_unf diff_ , _unf restore_. I say "UN-EF" vs U.N.F, but that's for
y'all to decide: I started by calling the project Unfucked and got
unfucked.ai, which if you know me and the messes I get myself into,
is a fitting purchase. The CLI command is `unf` and the Tauri
desktop app is titled "Unfudged" (kids safe name). How it works:
https://unfucked.ai/tech (summary below) The daemon uses FSEvents
on macOS and inotify on Linux. When a file changes, `unf` hashes
the content with BLAKE3 and checks whether that hash already exists
in the object store -- if it does, it just records a new metadata
entry pointing to the existing blob. If not, it writes the blob and
records the entry. Each snapshot is a row in SQLite. Restores read
the blob back from the object store and overwrite the file, after
taking a safety snapshot of the current state first (so restoring
is itself reversible). There are two processes. The core daemon
does the real work of managing FSEvents/inotify subscriptions
across multiple watched directories and writing snapshots. A
sentinel watchdog supervises it, kept alive and aligned by launchd
on macOS and systemd on Linux. If the daemon crashes, the sentinel
respawns it and reconciles any drift between what you asked to
watch and what's actually being watched. It was hard to build the
second daemon because it felt like conceding that the core wasn't
solid enough, but I didn't want to ship a tool that demanded
perfection to deliver on the product promise, so the sentinel is
the safety net. Fingers crossed, I haven't seen it crash in over a
week of personal usage on my Mac. But, I don't want to trigger
"works for me" trauma. The part I like most: On the UI, I enjoy
viewing files through time. You can select a time section and
filter your projects on a histogram of activity. That has been
invaluable in seeing what the agent was doing. On the CLI, the
commands are composable. Everything outputs to stdout so you can
pipe it into whatever you want. I use these regularly and AI agents
are better with the tool than I am: # What did my
config look like before we broke it? unf cat nginx.conf --at
1h | nginx -t -c /dev/stdin # Grep through a deleted
file unf cat old-routes.rs --at 2d | grep "pub fn"
# Count how many lines changed in the last 10 minutes unf
diff --at 10m | grep '^[+-]' | wc -l # Feed the last
hour of changes to an AI for review unf diff --at 1h | pbcopy
# Compare two points in time with your own diff tool diff
<(unf cat app.tsx --at 1h) <(unf cat app.tsx --at 5m) #
Restore just the .rs files that changed in the last 5 minutes
unf diff --at 5m --json | jq -r '.changes[].file' | grep '\.rs$' |
xargs -I{} unf restore {} --at 5m # Watch for changes in
real time watch -n5 'unf diff --at 30s' What was new
for me: I came to Rust in Nov. 2025 honestly because of HN
enthusiasm and some FOMO. No regrets. I enjoy the language enough
that I'm now working on custom clippy lints to enforce functional
programming practices. This project was also my first Apple-
notarized DMG, my first Homebrew tap, and my second Tauri app
(first one I've shared). Install & Usage: > brew
install cyrusradfar/unf/unfudged Then _unf watch_ in a
directory. _unf help_ covers the details (or ask your agent to
coach). EDIT: Folks are asking for the source, if you're
interested watch https://github.com/cyrusradfar/homebrew-unf --
I'll migrate there if you want it.
Author : cyrusradfar
Score : 56 points
Date : 2026-02-26 21:30 UTC (1 days ago)
(HTM) web link (www.unfudged.io)
(TXT) w3m dump (www.unfudged.io)
| s0a wrote:
| this seems insanely useful and well thought out. kinda surprised
| something like it doesn't already exist. def useful in the age of
| agents
| mplanck wrote:
| Yep, I've needed something like this a few times. Even when
| trying to be careful to commit every step to a feature branch,
| I've still found myself asking for code fixes or updates in a
| single iteration and kicking myself when I didn't just commit the
| damn thing. This will be a nice safety net.
| cyrusradfar wrote:
| Thank you! That's great to hear.
|
| I spent a bit of time being baffled nothing existed that does
| this. Then I realized that, until Agents, the velocity of
| changes wasn't as quick and errors were rare(er)
| datawars wrote:
| Thank you for pointing out a problem that I had (which I
| do!), solving with Time Machine and trying to make myself
| commit more requently - and for providing a solution! Looks
| very cool, too. If I close the terminal I started --watch in,
| will the watch continue?
|
| Writing this, I wanted to ask if the desktop app includes the
| CLI, but there it says it on your website :-) Thanks for
| thinking ahead so far, but then picking us up here and now so
| we can easily follow along into an unf* future!
|
| Looking forward to try it.
| cyrusradfar wrote:
| yes, it worked a lot so once you say watch it watches until
| you stop it, including through closing terminals, computer
| power off, etc. It should restart on reboot, but -- test it
| yourself and tell me if I'm wrong :) > unf
| watch # reboot > unf list
|
| it should say _watching_ on your directory still, if it
| stays crashed or something else. ping me at support at
| v1.co
|
| Just one human, two machines at my home can't replicate all
| configurations...
| datawars wrote:
| v1.co nice domain!
| rishabhaiover wrote:
| haha the NSFW toggle is crazy
| cyrusradfar wrote:
| Ha, the only feedback I needed :) I spent far too much time on
| the Unicorn exploding properly...
| bananapub wrote:
| why did you make it so complicated? magit has a `magit-wip-mode`
| that just silently creates refs in git intermittently so you can
| just use the reflog to get things back.
| cyrusradfar wrote:
| This was designed for any file save.
|
| From what I know (correct me) magit-wip-mode hooks into editor
| saves. UNF hooks into the filesystem.
|
| magit-wip-mode is great if your only risk is your own edits in
| Emacs. UNF* exists because that's no longer the only risk;
| agents are rewriting codebases/docs and they don't use Emacs.
| mpalmer wrote:
| This is so cool to have made yourself. How would you compare this
| to the functionality offered by jujutsu? I love the histogram, it
| was the first sort of thing I wanted out of jujutsu that its UI
| doesn't make very easy. But with jj the filesystem tracking is
| built in, which is a huge advantage.
| cyrusradfar wrote:
| I'm not a user, but I looked at the site and it looks like jj
| snapshots when you run a jj command. UNF snapshots
| continuously.
|
| If an AI agent rewrites 30 files and you haven't touched jj
| yet, jj has the before-state but none of the intermediate
| states. UNF* captured every save as it happened, at filesystem
| level.
|
| jj is a VCS. UNF is a safety net that sits below your VCS.
| - UNF* works alongside git, jj, or no VCS at all -
| No workflow change. You don't adopt a new tool, it just runs in
| the background - Works on files outside any repo
| (configs, scratch dirs, notes) as it doesn't require git.
|
| They're complementary, not competing.
|
| W.r.t. to the histogram, this is my fav feature of the app as
| well. Session segmentation (still definitely not perfect)
| creates selectable regions to make it easier, too. The algo is
| in the CLI as well for the Agent recap (rebuilding context)
| features.
| lexluthor38 wrote:
| To be fair, jujutsu has a watchman feature which uses inotify
| to create snapshots on file change as well. Your tool
| probably has a more tailored UX to handling these inter-
| commit changes though so there could still provide
| complementary value there.
| mpalmer wrote:
| Yes, I was thinking of the watchman integration. And I also
| really love the DSLs it gives you for selecting change sets
| and assembling log formats.
| wazzaps wrote:
| FYI all Jetbrains IDEs include this, as long as they are open on
| the codebase. It's called "Local history".
| its-kostya wrote:
| I love to use the terminal, and I still do. But as much as I
| love to unfu*k my local nvim setup, I much rather pay a company
| to do it for me. Set up vim bindings inside jetbrains and
| everything comes with batteries included, along with a kick-ass
| debugger. While my colleagues are fighting opencode, I pointed
| my IDE at the correct MCP gateway and everything "just works"
| with more context.
|
| Thought I'd share the data point to support jetbrains
| heeen2 wrote:
| vscode and its forks as well (for files it saves)
| gschrader wrote:
| I think it only keeps history for user edited files, agent
| edited files don't seem to end up in it for me (Claude code)
| but maybe it works with other agents with the proper plugins
| I'm not sure.
| cyrusradfar wrote:
| +1 OP here, this is the problem I'm solving for. Agents use
| tools and may be in multiple places editing; therefore, you
| _need_ to watch the file system.
| williamstein wrote:
| Is this open source or source available?
| cyrusradfar wrote:
| OP here, responded to similar question here:
| https://news.ycombinator.com/item?id=47185781
| notfried wrote:
| I love the website; the design, the video, the NSFW toggle, the
| simplicity.
|
| I love the idea; definitely something I ran into a few times
| before and wish I had.
|
| Unfortunately, I am not installing a closed-source daemon with
| access to the filesystem from an unknown (to me) developer. I
| will bookmark this and revisit in a few weeks and hope you had
| published the source. :)
| popalchemist wrote:
| Agreed on all counts. It looks great! Just can't trust it
| unless it's transparent.
| cyrusradfar wrote:
| Totally understandable.
|
| I didn't open up the source for this as I have a mono-repo with
| several experiments (and websites).
|
| Happy to open the source up and link it from the existing
| website.
|
| I've started to have an Agent migrate it out, and will review
| it before calling it done. Watch
| https://github.com/cyrusradfar/homebrew-unf
|
| Edit: You can download the current version now:
| https://github.com/cyrusradfar/homebrew-unf/archive/refs/tag...
| ifh-hn wrote:
| I have used fossil in a similar way, also local, and sqlite
| based. Admittedly you have to add files to it first but setting
| it running via cron was simple enough. Though it wasn't be ause I
| let an AI access all my stuff.
| monster_truck wrote:
| Where is the source? I'm not going to rely on or trust anything
| this important to code I can't read.
| cyrusradfar wrote:
| OP here, responded to a similar concern here:
| https://news.ycombinator.com/item?id=47185781
| overcrowd8537 wrote:
| love the idea of this, but echoing others... closed source daemon
| with access to all files is a 100% non-starter.
| cyrusradfar wrote:
| OP here, responded on the topic:
| https://news.ycombinator.com/item?id=47185781
| alunchbox wrote:
| Just use Jujutsu
| ncr100 wrote:
| A useful idea!
|
| Alternative - version files and catalog those versions (most of
| the work, with "Unfucked", appears to be catalog management),
| building it on top of a Versioning File System.
|
| E.g. NILFS logging file system, logs every block-change
| (realtime)
|
| more:
|
| - NILFS https://en.wikipedia.org/wiki/NILFS
|
| - topic https://en.wikipedia.org/wiki/Versioning_file_system
___________________________________________________________________
(page generated 2026-02-27 23:01 UTC)