DEV Community

nk sharma
nk sharma

Posted on

I built a VS Code extension that saves checkpoints without commits

You finish step 1 of a feature and you don't want to commit yet, so you stage it. Then step 2 happens, and you're staring at one pile of changes again with no way to tell the steps apart.

I kept hitting this, so I built Waypoint: a free, open-source VS Code extension that saves hidden checkpoints between steps, without commits, and without touching your branch, staging area, stash or history.

Waypoint - Git Snapshots

Waypoint sidebar and diff

What it does

  • One shortcut (Cmd+Opt+K / Ctrl+Alt+K) creates a checkpoint.
  • Expand a checkpoint to see only what that step changed, with a side-by-side diff.
  • Working changes shows what you've done since the last checkpoint.
  • Compare any two checkpoints, or a checkpoint with your current files.
  • Restore a checkpoint (or a single file), with an Undo button.
  • One list per branch, and a filter by file path.

Checkpoints include untracked files and respect .gitignore.

How it works

Git already has everything needed, so Waypoint is a thin layer over git plumbing:

# work on a copy of the index, so your real staging area is never touched
cp .git/index /tmp/waypoint-index
export GIT_INDEX_FILE=/tmp/waypoint-index

git add -A                                    # snapshot the whole working tree
tree=$(git write-tree)                        # turn it into a tree object
commit=$(git commit-tree "$tree" -p HEAD -m "Checkpoint 1")
git update-ref refs/checkpoints/br-main/$(date +%s) "$commit"
Enter fullscreen mode Exit fullscreen mode

Each checkpoint is a full snapshot stored as a hidden commit under a private ref. Git stores identical file contents only once, so ten checkpoints are cheap. The sidebar just runs diffs between neighbouring checkpoints.

Because everything lives inside .git, running git reset --hard or Discard All Changes can't touch your checkpoints.

Guard checkpoints

The part I like most is an automatic safety net. Waypoint keeps a quiet baseline snapshot of your files. If HEAD moves because of a reset, pull, checkout or rebase, or if six or more files change outside the editor (a bulk discard, a code generator, an AI agent writing straight to disk), it saves that baseline as a checkpoint named something like Guard ยท before reset: moving to HEAD~1.

So an uncommitted edit that a git reset --hard would have erased is sitting in the sidebar, one click from being restored.

What it isn't

  • Not a backup. Checkpoints are local, aren't pushed, and are gone if you delete or re-clone the repo.
  • Not a replacement for WIP commits. If you're happy committing throwaway work and squashing later, you may not need this.
  • Not instant on huge repos. Refreshing Working changes snapshots the tree, which can be slow in very large ones. There's a setting to turn off the automatic part.

It makes no network requests and has no telemetry.

The bug I shipped

Version 0.1.1 had a startup bug. I'd left a duplicate command registration in the code, and VS Code throws on that, which aborts activate(). Everything registered after the duplicate silently never existed, so Delete, Compare and Filter all showed "command not found".

The fixes in 0.1.3: a small script that checks every command in package.json against the code, a check for duplicate IDs, and a written test plan I run before each release.

grep -A1 'registerCommand' src/extension.ts | grep -o '"waypoint\.[A-Za-z]*"' | sort | uniq -d
Enter fullscreen mode Exit fullscreen mode

If that prints anything, you have a duplicate.

Try it

This is v0.1.3, so expect rough edges. How do you handle this problem today: WIP commits, stash, or something else? And what would make this useful for you?

Top comments (0)