Undo Is Not a Time Machine: How to Keep a Version History of Your Notes That Outlives the App

Undo is a session buffer; it dies when you close the tab. A version history is durable, named, and restorable. Cloud note apps offer one — but they rent it to you in a capped window that vanishes when you stop paying or when the window slides past your edit. Plain-text notes plus a local version-control tool give you an unbounded, owned history on your own disk. This guide shows the exact workflow to keep it and roll back forever.

The fix is not a clever app. It is a property of how your notes are stored. Keep them as plain Markdown files you own, point a version-control tool at the folder, and every past state of every note becomes recoverable — for free, locally, with no expiry. The tool here is git, the same engine that tracks the world's software. It is the engine, not the gatekeeper, and the principle holds even if you reach for something simpler.

How long does a cloud note app keep your version history?

A cloud app keeps your history in a window scaled to your subscription tier — and the window only exists while you keep paying. Notion's own help center sets it plainly: "7 days if you're on a Free Plan," "30 days if you're on a Plus Plan," "90 days if you're on a Business Plan."¹ Pass the window, and the old version is gone.

Even the "unlimited" tier is leased, not owned. Notion reserves the longest retention for the top of the ladder: "Any number of days if you're on an Enterprise Plan."¹ That phrasing is exact, and it is the whole point. Unlimited history is real — and it is contingent on an active enterprise contract. Stop paying, downgrade, or let the company change the terms, and the depth you relied on is no longer yours.

This is not a knock on the feature. A revision window is genuinely useful, and recovering yesterday's draft from the cloud is a real convenience. The issue is structural. You are renting access to your own past, on a meter, in a format the vendor controls. The version history exists at someone else's discretion, and the lookback depth has a price tag.

What does "owning" your version history actually mean?

Owning your history means every past state of every note lives on your disk — in a format you can read without the app, with no retention limit and no subscription gate. The mechanism is git, which the Pro Git book describes as fundamentally local: "Most operations in Git need only local files and resources to operate."²

The difference is custody, not just convenience. With a cloud app, the history lives on the vendor's servers and you query it through their interface within their window. With a local version-control tool, "you have the entire history of the project right there on your local disk."² No network. No account. No meter. The history is a folder you can back up, copy to a new machine, or open in twenty years.

Plain text is what makes this cheap and durable. A Markdown note is just lines of text, so a version-control tool can store every revision as a tiny diff and show exactly which words changed between any two points in time. A proprietary blob cannot be diffed line by line — so the format you write in decides whether an owned history is even possible.

This is the same ownership logic behind getting your notes out of a dying app. The two are distinct moves: export is how you leave with your notes intact; a local history is how you go back to a version you already lost.

Why files outlast the apps that made them

Files outlast apps because a file is a durable artifact — an app is a temporary delivery mechanism. Steph Ango, the CEO of Obsidian, put the durability argument in one line: "In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last."³

Version durability is the same argument, one layer deeper. Ango frames the philosophy as a test of control: "File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control."³ If your current note must be a file you control, so must every previous version of it. A history trapped in a vendor's revision panel fails the same test the live note would.

Obsidian itself proves the principle works on-device. Its free File recovery core plugin keeps local snapshots without any account: "By default, snapshots are saved a minimum of 5 minutes from each other, and kept for 7 days."⁴ That is an owned, local safety net you already have if you use the app — short, but yours, and a gentle on-ramp to the idea before you ever touch a command line.

The recovery workflow: a version history you own in five moves

The workflow is one setup step and four recovery moves against a folder of .md files. Initialize a repository once, commit on a schedule so each save becomes a named point in time, then use the log to find a past state, check it out to restore it, and keep the reflog as a safety net. None of it touches the cloud.

A note on scope before the steps: this is the git path, and git has a learning curve. The principle — own your history, do not rent it — stands even if you use a simpler tool. A dated cp of the folder, your operating system's built-in snapshots, or Obsidian's File recovery all keep an owned history. Use the level you are comfortable with; the steps below are the most powerful version, not the only one.

Step 1 — Initialize once

Run this one time inside your notes folder. It creates a hidden .git directory that will hold every future version, entirely on your machine.

cd ~/notes
git init
git add .
git commit -m "First snapshot of my notes"

After this, your folder is a repository. Nothing left your computer. The first commit is your baseline — the earliest state you can ever return to.

Step 2 — Commit on a schedule

A version history is a habit, not magic. The single load-bearing caveat in this entire workflow comes from the Pro Git book: "anything you lose that was never committed is likely never to be seen again."⁵ History only protects what you have committed, so the commit step is the one you cannot skip.

git add .
git commit -m "Reworked the project outline"

Run this whenever you finish a meaningful edit — end of a writing session, before a big rewrite, after capturing something you care about. To remove the reliance on memory, wire it to a schedule (a daily cron job) or a save hook so commits happen on their own. The reassurance on the other side is also from Pro Git: "Remember, anything that is committed in Git can almost always be recovered."⁵

Step 3 — Find the version you want with git log

To travel back, first find the point in time. git log lists every commit with its message and a unique identifier; scoping it to one file shows only that note's history, including the moment it was deleted.

git log --oneline                       # every snapshot, newest first
git log --all --full-history -- notes/project.md   # one file's full history, even after a delete

Read the commit messages, find the version you want, and copy its short identifier (the hash). To see exactly what changed between two points, git diff <old-hash> <new-hash> -- notes/project.md prints the line-by-line difference — the thing a proprietary blob can never give you.

Step 4 — Restore a past version with git checkout

With the hash in hand, restore the file. To recover a single note to a past state without disturbing anything else, check out that one file from that one commit. To bring back a file you deleted, check it out from the commit before the deletion.

git checkout <hash> -- notes/project.md          # restore one note to a past version
git checkout <delete-commit>^ -- notes/lost.md   # bring back a deleted file (^ = the commit before)

The restored version lands in your folder, ready to commit as the new current state. You have rolled back time on a single note while leaving the rest of your vault untouched.

Step 5 — Keep the reflog as your safety net

If a destructive command moves you somewhere you did not mean to go, the reflog brings you back. The git documentation defines it precisely: "Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository."⁶ It is a local record of every place your history's pointer has been — including the one you just left.

git reflog                    # every position HEAD has held, even ones git log hides
git checkout HEAD@{2}         # jump back to where you were two moves ago

The reflog is why "committed in Git can almost always be recovered" holds even after a mistake. As long as you committed the work at some point, the reflog usually still knows where it went.

Common mistakes (and the honest limits)

Most failures here are habit failures, not tool failures — and a few are honest limits worth stating plainly before you trust the system. The version history protects committed work, not unsaved work; the cloud's history is real but leased; and git rewards a routine, not heroics. Name the limits first, then build the habit around them.

• Forgetting to commit. This is the only failure that loses real work. Uncommitted edits are invisible to git, and "anything you lose that was never committed is likely never to be seen again."⁵ Automate the commit on a schedule or a save hook.
• Thinking plain files alone are a history. Plain text is what makes diffs and clean restores possible; the version-control tool is what keeps the history. Files plus a VCS — not files alone.
• Treating undo as a backup. Undo is a volatile session buffer that empties when you close the app. It is not a time machine; only a committed history is.
• Dismissing the cloud entirely. A cloud app's revision window is a real, convenient feature. The fair critique is narrow: it is bounded and leased, not owned. Obsidian's paid Sync history runs longer — "On the Standard plan, notes are retained for 1 month, while on the Plus plan, they are kept for 12 months"⁷ — and even that long, useful window is a tiered subscription, with attachments shorter still: "For attachments, older versions are stored for two weeks."⁷
• Skipping the learning curve when you do not need it. If git feels heavy, do not gatekeep yourself. A dated folder copy or your system's built-in snapshots still give you an owned history. The principle matters more than the tool.

That last point ties to a sibling seam: attachment history is the shortest-lived of all, which is exactly the problem covered in what breaks when you add an image to a Markdown note.

Frequently asked questions

How long does Notion keep page history?

Notion keeps page history in a window set by your plan: "7 days if you're on a Free Plan," "30 days if you're on a Plus Plan," and "90 days if you're on a Business Plan," with "Any number of days if you're on an Enterprise Plan."¹ The window exists only while the subscription is active, and once a change scrolls past the limit it is gone.

Can I recover a previous version of a note after the window expires?

In a capped cloud app, no — once a change passes the retention window for your plan, that version is deleted. With plain-text notes under a local version-control tool, yes, and forever: "anything that is committed in Git can almost always be recovered."⁵ The single condition is that the version was committed; uncommitted work is not protected.

Does Obsidian keep version history offline or locally?

Yes. The free File recovery core plugin keeps local snapshots on your device with no account: "By default, snapshots are saved a minimum of 5 minutes from each other, and kept for 7 days."⁴ That is separate from Obsidian's paid Sync history, which is longer but cloud-based and tiered.⁷

How do I find when a file was deleted in git and restore it?

Find the deletion with git log --all --full-history -- <file>, which shows the file's complete history including the commit that removed it. Then restore it from the commit just before that one with git checkout <delete-commit>^ -- <file>. The ^ means "the parent commit," the last state where the file still existed.²

What is git reflog and how does it recover lost work?

The reflog is a local record that, per the git docs, captures "when the tips of branches and other references were updated in the local repository."⁶ After a reset or a checkout that loses your place, git reflog lists every position your history pointer has held, and git checkout HEAD@{n} returns you to where you were — the safety net behind "almost always be recovered."⁵

Is undo the same as version history?

No. Undo is a volatile session buffer that lives in memory and empties when you close the app or reload the tab. A version history is durable: each save is a named, dated point in time stored on disk that you can diff against and restore weeks or years later. Undo protects the last few keystrokes; an owned history protects every version forever.

Do I have to use git to own my version history?

No. Git is the most powerful path, but the principle is what matters: keep an owned, unbounded history rather than renting a capped one. A dated copy of the folder, your operating system's built-in snapshots, or Obsidian's free File recovery all keep history on your own device. Reach for the level of tooling you are comfortable maintaining.

The version history that survives is the one you store in files you own. Notes kept as plain Markdown on your own device — the way MNMNOTE keeps them — are exactly what makes that owned, unbounded history possible, because plain text diffs and restores where a proprietary blob cannot.