stowe

Git for files, any remote. Version-control large/binary files (music, photos, video, datasets) where git chokes — content-addressed, deduped, with a dumb pluggable remote. No branches, no content diffs.

cargo install stowe

stowe init
stowe add -A                          # or: stowe add <paths...>
stowe commit -m "import"
stowe remote add origin local:/mnt/backup/music
stowe push                            # upload changed content + history
stowe pull                            # sync another machine to the latest

Features

• Dedup — every file is named by its blake3 hash, so identical/unchanged content is stored once.
• Fast rescans — a file is re-read only when its size or mtime changes.
• Move tracking — renames are matched by content hash; audio also carries a fingerprint (hash of the decoded PCM, via Symphonia), so a song that's renamed and re-tagged still reads as a move, not a delete + add.
• git-style status — staged / unstaged / untracked, with deleted/modified/renamed/new.

Remotes

The backend is picked from the URL:

• local:<path> — folder, mounted drive, or NAS. Anything you can mount is a remote, so Google Drive / Dropbox / FTP work today by mounting them (rclone mount gdrive: ~/gdrive) and pointing local: at the mount.
• s3://<bucket>[/<root>] — any S3-compatible store (AWS, Backblaze B2, MinIO). Credentials from the AWS_* env vars; set AWS_ENDPOINT_URL for B2/MinIO.

A populated remote is a bare repo — refs/main, commits/<hash>.json, objects/<ab>/<rest> — so any machine can read it and rebuild the library. Native gdrive: / rclone: / ftp:// are planned, behind the same interface.

Status

Early: linear history (one main), last-write-wins push, whole-file objects (no chunking). stowe restore/checkout (recover a committed file) and stowe gc (prune unreferenced history) are planned.

License

AGPL-3.0-only.