chip documentation

chip is a changeset-oriented version control system — a Git alternative, not a clone. This server hosts chip repositories and speaks the chip sync protocol over gRPC.

How chip differs from Git

• No staging area. There is no add; the whole working tree is snapshotted on commit.
• Stable change-ids. Every change has a change-id that persists across rewrites (amend/rebase), separate from its content (commit) hash.
• First-class conflicts. A conflicting merge never aborts — it produces a conflicted change you resolve with a normal commit.
• Universal undo. chip undo reverses the last operation via an operation log.

Getting started

1. Create an account (or log in).
2. Pick how the CLI authenticates:
   • HTTP — create an API token and run chip login (the token is stored locally).
   • SSH — add your public key under SSH keys; no token needed.
3. Create a repository from New repository (or chip repo create), then push to it.

chip register https://chip.shiftorbiter.com -u alice -e you@example.com   # or: chip login https://chip.shiftorbiter.com -u alice
chip clone https://chip.shiftorbiter.com/alice/<repo>                      # over HTTP (bearer token)
chip clone ssh://chip@<host>/alice/<repo>            # over SSH (your key)

Everyday workflow

There is no staging step — edit files, then commit the whole tree.

chip init                     # start a repository
chip commit -m "message"      # snapshot the working tree as a new change
chip status                   # what changed since the last commit
chip diff                     # unified diff of those changes
chip log                      # history, organized by change-id
chip show [rev]               # a change's metadata + diff (default: @)
chip undo                     # reverse the last operation

Branching & history

chip bookmark <name>          # create/move a bookmark (named branch)
chip checkout <name|commit>   # switch and update the working tree
chip checkout -b <name>       # create a bookmark at HEAD and switch
chip merge <name|commit>      # three-way merge (conflicts stay first-class)
chip rebase <name|commit>     # replay the branch onto a new base (keeps change-ids)
chip cherry-pick <rev>        # copy one commit's change onto the current change
chip amend [-m msg]           # rewrite the current change, keeping its change-id
chip resolve                  # clear resolved conflict markers
chip stack                    # show the stack of changes above the trunk
chip evolution [rev]          # a change's versions over time (across amend/rebase)

A rev may be a bookmark, tag, @, or a commit id — abbreviated ids (the 12-char prefix in chip log) work too.

Browsing on the web

A repository's page shows its bookmarks, tags, recent changes, and a rendered README.md. From there:

• Browse files — navigate the tree and open blobs with syntax highlighting.
• Open any change to see its diff; open a file's History to see the commits that changed it.
• URLs take a revision (bookmark, tag, or commit id), e.g. /alice/<repo>/tree/main.

Change requests

Propose merging one bookmark into another on a repository's Change requests page: review the combined diff, comment, approve or request changes, and merge in the browser. Merges are three-way and keep conflicts first-class (a conflicting merge is surfaced, not forced).

Coming from Git

chip import git <path> [dir]  # import a local Git repo's full history into chip

Working with this server

chip remote add origin https://chip.shiftorbiter.com/alice/<repo>
chip push origin [--force]    # --force allows a non-fast-forward update
chip pull origin              # fast-forward; warns (never clobbers) on divergence
chip pull origin --rebase     # on divergence, rebase local changes onto the remote
chip pull origin --merge      # on divergence, create a merge commit

The first push to a repository under your own account creates it automatically. HTTP remotes use a bearer token; SSH remotes use your key.

Settings

• API tokens — create and revoke tokens that authenticate the CLI over HTTP (optionally set an expiry).
• SSH keys — add your public key to clone, push, and pull over SSH without a token.

Access & security

Repositories are public or private, with read/write collaborators managed by the owner on the repository page. Repository object data is encrypted at rest (AES-256-GCM). Passwords are Argon2-hashed; CLI tokens are stored only as hashes (revocable, optionally expiring); failed logins are rate-limited; and pushes are fast-forward unless forced.