Everything you need, and not much of it.
Riggit has one screen and one button, so this is short. Installing, a first commit, how your name and email get chosen, moving your licence between machines, and what the error messages mean.
Installing
Download the build for your platform from the download page and open it. There is nothing to configure afterwards.
Riggit needs Git already installed, because it drives yours rather than bundling its own. That is what keeps your SSH keys, credential helpers, hooks and remotes working untouched. If git --version answers in your terminal, you are ready.
The current builds are not code signed, so both macOS and Windows will question them on first open. The download page walks through each, and it is a one time step per machine.
Your first commit
- 01Add a repository. Use the plus button in the sidebar and pick the folder, or drag it onto the window. Pick the folder the repository lives in, not a folder inside it.
- 02Write a message. The same message you would have written at the time.
- 03Choose the date and the time. Both, not just the date. A backfilled week reads as a worked week because the commits land at plausible hours.
- 04Decide about staging. Stage all picks up everything that has changed. Leave it off and Riggit commits exactly what you have already staged yourself.
- 05Decide about syncing. Off by default. With it on, Riggit pulls anything new from the remote, makes the commit, then pushes. With it off the commit stays on your machine until you say otherwise.
- 06Decide about empty commits. Off by default, and only for work that left no diff of its own: a review, a pairing session, an afternoon reading the codebase.
- 07Commit. The repository state above the button refreshes, and the commit is a completely ordinary Git commit from that moment on.
Your first three commits are free and need no account. After that the app asks for a licence key.
Name and email
Commits carry an author, and Riggit works out yours rather than asking you to type it again. It looks in order: the repository's own Git config, then your global config, then the author of the last commit in that repository. It asks only when all three come up empty.
Whatever it settles on is shown in Settings, per repository, so you can see what a commit will be attributed to before you make one. If you change it there you choose whether that applies to the one repository or to every repository on the machine, which is the same local and global distinction Git itself uses.
Use the same email your Git host knows about. That is the one thing worth checking, because a commit authored under an address your host does not recognise will not be attributed to you, no matter what date it carries.
Licence and devices
One seat covers one device at a time. Activating on a machine claims the seat; releasing it from Settings frees it for another. There is no limit on how often you move, and no waiting period.
Riggit checks the licence at launch and then leaves you alone. If it cannot reach the licence server it keeps working for seven days on the last successful check, so a bad connection or a flight does not lock you out of your own repositories.
Cancelling stops the renewal. The app keeps working until the period you have paid for ends, then drops back to the free trial. Nothing is removed and no commit is affected: every commit Riggit has made is a normal Git commit and belongs to your repository, not to us.
Troubleshooting
That folder is not a Git repository. Riggit works on folders that Git already tracks. Run git init in the folder, or pick the folder that contains the repository rather than one beside it.
Another Git process seems to be running. Something else has the repository open, often an editor mid operation. Wait for it to finish and try again.
Git refuses the repository as unsafe. Git will not operate on a repository owned by a different user account. This usually means the folder was copied from another machine or sits on an external drive. Git's own message names the command that fixes it.
The commit worked but the push did not. That is a complete success followed by a separate failure, and Riggit says so rather than reporting the whole thing as broken. Your commit exists. Push it whenever you are back online, from Riggit or from your terminal.
Your branch and the remote have both moved on. Riggit only ever fast-forwards. It will not merge two histories for you, and it will never rebase, so when both sides have commits the other does not, it stops. Your commit is already made and safe. Merge in your terminal, then sync again.
The remote changed files you had edited. There was nothing to fast-forward onto without overwriting your work, so Riggit left it alone. Again, the commit is made. Merge in your terminal when you are ready.
The commit is not showing on my profile. Two usual causes. The commit has not been pushed yet. Or its author email is not one your Git host has associated with your account, which you can check in your host's email settings.
What leaves your machine
Your code does not. Riggit talks to two servers: the one that checks your licence, and GitHub, which it asks at startup whether a newer version has been published, and which it goes further with only if you choose to sign in. Neither is told which repositories you have opened or what is in them.
The only other thing that goes anywhere is the push you explicitly asked for, to the remote you already had, over the connection Git was already using. The privacy policy says the same thing at greater length.
Still stuck
Email support with what you did, what you expected and what happened instead. If Riggit showed you an error, quoting it verbatim saves a round trip.