CodeCraft Chronicles

Groove: Save States for Solo Development

Groove (GROOVE Retains Older Object Versions Effortlessly): A Nim tool for solo developers who need frequent checkpoints and clean releases — the layer before git, not a replacement for it.

The Solo Developer's VCS Problem

Traditional version control was designed for teams. Meaningful commits, descriptive messages, linear history that others can read. This works well when other people read your commits. When you're the only one working on something, the overhead becomes friction.

Solo development tends toward endless WIP cycles. You make twenty small edits before anything is worth committing. You commit anyway — "wip", "more wip", "fix that thing" — and your history becomes noise. Then you need to release something and spend twenty minutes squashing and rebasing to produce a clean history nobody asked for.

Groove separates two concerns that git conflates:

Between releases you wip freely. On release, all wips collapse into the version. History stays clean without squashing.

Installation

nimble build
cp groove /usr/local/bin/

Requires Nim 2.0+. No other dependencies.

Daily Commands

groove wip              # save current state (undo point)
groove undo             # restore previous wip
groove redo             # step forward through wip history

groove release v0.1     # consolidate wips → named release
groove ls               # list wips and releases
groove show v0.1        # inspect a release

groove diff             # changes since last wip
groove diff v0.1        # changes since a release

This is the entire interface. There is no branching, no merging, no remote. Groove is not trying to be git.

When to Use Groove

Groove is useful for the period when a project is actively being drafted — the phase before it deserves a public repository. You're exploring a design. You're writing a library but haven't decided on the API. You're building something for yourself.

During this phase, git's overhead is real. Naming every save. Deciding what to stage. Maintaining a coherent commit history for an audience of one. Groove removes that overhead.

When the project is real — when others will contribute, when you need blame or bisect, when a CI pipeline needs to run — push to git. Groove can export to a git repository at any point:

groove export --git ./myproject.git

The releases become git tags. The wip history is collapsed (it was never meant to be permanent).

The Release Model

A release in Groove is an immutable named snapshot:

groove release v0.2 --message "Search endpoint complete"

All wips since the previous release are consolidated. The wip chain is cleared. You start fresh for the next release.

wip → wip → wip → wip → release v0.1
wip → wip → release v0.2
wip → wip → wip → release v0.3 ← you are here

This matches how solo work actually happens: sprints of exploration, then a stable point. The release is the unit of history worth keeping.

Why Nim

Groove is written in Nim because the storage model — versioned file trees — maps naturally to Nim's system programming capabilities. The tool needs to hash files, detect changes, serialize state, and do all of it quickly.

Nim compiles to C, produces small binaries, and has no runtime to install. groove is a single executable. You compile it once, copy it anywhere.

The storage format is plain directories — no binary database format to corrupt, no external tool to inspect it. Each wip is a directory named by timestamp hash. Each release is a tagged symlink. You can examine the store with ls and recover data with cp if anything goes wrong.

What Groove Is Not

It's worth being explicit:

Groove is the layer before git. It keeps you from losing work while you figure out what you're building.

License

MIT

Comments