|
2 weeks ago | |
---|---|---|
README.md | 2 weeks ago | |
solo | 2 weeks ago |
README.md
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