solo

A simple, single branch, version control system for individuals.

Who is this for?

No one, really... me maaaaybe? It has been an educational exercise. However, if I add the concept of remotes I may end up using it a bit. Mot of my slope modules/projects consist of only a small handful of files, often in a single directory, that I do not develop collaboratively... which may suit solo well and vice versa.

Commands

solo essentially takes full backups of the current work tree and copies them to snapshots/commits in the .solo directory of a repository. It can then do a few simple things with those commits. All commands must be run from the repository root. The available commands are as follows:

solo init

Initializes a directory tree as a solo directory. The command takes no arguments and mostly just sets up the needed file tree.

solo commit [[commit-message]]

This commits a new snapshot to the .solo/snapshots folder. Unlike git, solo is a bit inefficient (but also more understandable to mere mortals) and always saves the full working tree... not just changes. As such, there is no need to add or remove. The concept of an ignore list may be added later. The commit message is optional but highly recommended.

solo tag [[commit] [tag-name]]

Tags a given commit with the given tag name. If no arguments are given the available tags will be listed. Tags can be recalled with use exactly like a commit but server as way to document meaningful commits like major version releases, etc.

solo pick [commit] [file] [[to-file]]

Copy the given file from the given commit into the current work tree. file should be a relative path from the root directory as the file was at time of commit (so if the file was ./test/my-test.c relative to the repo root when you committed, that is what you use. Do not give a path based on the location within the .solo folder). use will clobber an existing file if one exists, but that can be avoided by passing to-file: a path that you would like to write the file to. The to-file path can be outside of the repo, but if a relative path is given it will be relative to the repo root. This is an easy way to revert a single file to a prior state without having to call use to bring back the whole work tree of a commit/tag.

solo use [[commit|tag-name]]

Reverts the workspace to the state of the given commit. If no commit is provided then the most recent commit will be used, effectively making the command function similar to git reset --hard.

solo status

Reports what files have been added, deleted, or changed since the last commit.

solo diff

Shows the actual changes between the current work tree and the last commit.

Files

The file .soloignore can be placed in the repo root if you like. Each line in the file can be a relative path to a file, folder, or group of files (via globbing * or **). Any file listed in .soloignore will not be committed and will not show up for purposes of status or diff.

Initializing a repository will place a .solo folder in the root folder of the repository. This folder contains all of the solo data. If you ever want to stop using solo for a project or start from scratch with the given repo simply recursive delete the folder (rm -rf ./.solo). In general it is likely best to not mess around in the .solo folder, as the program will handle all of the edits and may become "confused" if things are not kept how it likes them ;)

Dependencies

solo requires the slope language interpreter to be installed. It needs to be version 0.5.16 or higher as it uses some newer features (at time of writing). Other than that there are no additional slope modules needed. If you are needing to build the slope interpreter you will need a Go compiler >= version 1.16