{% extends "base.html" %} {% block title %}Help{% endblock %} {% block content %}

Help using {{ shell.site }}

Getting started

{{ shell.site }} hosts Oxygen repositories. You work with them through oxy, the Oxygen client; the hub shows them, reviews them and runs their pipelines. Every command below is filled in for this hub.

  1. Install oxy: build it from the oxygen repository with cargo build --release and put target/release/oxy on your path.
  2. Say who you are and make a signing identity (next section).
  3. {% if shell.user.is_some() %}Create a personal access token{% else %}Register, then create a personal access token under Settings › Tokens{% endif %} with repo:write. It is shown once; keep it in oxy's configuration, not in scripts.
  4. {% if shell.user.is_some() %}Create a repository{% else %}Create a repository with + NEW{% endif %} and push to it (below). An empty repository shows the same commands, with its own address.

oxy doctor checks your identity, configuration and remotes, and says what to do about any problem.

Your identity

Oxygen changes are signed. Your identity is a key pair (Ed25519 with ML-DSA-65) kept under ~/.config/oxy; the public part travels with your changes.

{% let cmd = "oxy config --user author.name \"Your Name\"\noxy config --user author.email you@example.com\noxy identity create\noxy config --user core.sign change" %}
{{ cmd }}

Link the key to your account under {% if shell.user.is_some() %}Settings › Keys{% else %}Settings › Keys{% endif %}: the page gives you a challenge to sign with oxy identity sign-challenge, which proves you hold the key. Linked keys show on your profile, and the hub can then tell which signed changes are yours.

Pushing

From a checkout, add the repository as a remote, give it your token, and push{% if q.ca_url.is_some() %}. This hub's certificate is self-signed, so the commands also save it and point the remote at it{% endif %}:

{% let cmd = q.connect(self.repo_url().as_str()) %}
{{ cmd }}

An empty repository takes its identity from the first push, so every later clone shares it. oxy push {{ q.remote }} sends the current bookmark; oxy push {{ q.remote }} --bookmark NAME another one. Tags travel with pushes.

A Git history comes across with oxy git import --branch main path/to/git-checkout NAME: every commit becomes a change, and the result can be pushed like any other repository.

Cloning

{% let cmd = self.clone_cmd() %}
{{ cmd }}

Public repositories clone without a token. For private ones, and to push back, set oxy config remote.origin.token YOUR-TOKEN{% if q.ca_url.is_some() %} and oxy config remote.origin.ca {{ q.ca_file }}{% endif %} in the clone. oxy pull origin brings in what others pushed; there is no merge commit, because Oxygen changes combine by themselves.

Proposals

A proposal asks for a bookmark's changes to be added to another bookmark, like a pull request. Push your bookmark, then open one from the repository's Proposals tab, from the compare page's Propose this, or from a fork.

  • A proposal is always tested and reviewed on its projected state: exactly what the target will hold once it lands. It never goes stale, and there is nothing to rebase.
  • Review comments are anchored to lines' atoms, so they stay on the right line through later pushes.
  • An approval can be a seal: your signature over the proposal's changes (oxy seal), which anyone can check offline.
  • Land from the page, or from a client with oxy proposal land URL, which signs the landing with your own key.

Letting the hub act for you

Edits in the browser and landings from the proposal page are changes too, and they must be signed. The hub signs them as your delegate, only if you allow it. Allowing it is a one-off step:

{% let cmd = self.delegate_cmd() %}
{{ cmd }}

Then link your identity again under Settings › Keys, so the hub sees the delegation. You can withdraw it at any time with oxy identity delegate remove; a repository's trust policy still decides whether a delegated change may update a bookmark.

Pipelines

Pipelines run in OxygenFlow. Put a pipeline in .flow/pipeline.kdl and push: each job runs in its own microVM with no network, and its result shows on the repository's Flow tab and as a check named flow/JOB on proposals. A site administrator enables Flow for a repository.

Instead of a badge, a README can carry a state stamp:

{% let cmd = "[![flow](.flow/stamp)](.flow/run)" %}
{{ cmd }}

It shows the result for the state you are looking at (a tag shows the tag's result), names that state, and carries each job's receipt hash.

Keyboard

/Search
g cThe repository's code
g hHistory of the bookmark you are on
g pProposals
g iIssues
g bBookmarks
g tTrust
yReplace the address with a permalink to this exact state (files and trees)
click a line number, Shift-click anotherSelect lines; copy them or a permalink to them
?The keyboard sheet

Coming from GitHub

GitHubHereWhat is different
commitchangeA change records edits, not a snapshot, and names the changes it depends on. Changes that do not touch the same lines combine in any order with the same result, so there are no merge commits. A change keeps its identity when it is rebased or squashed.
commit SHA, treestateThe files a set of changes makes. A state is addressed by its heads (a1b2…+c3d4…); checks, stamps and permalinks belong to states.
branchbookmarkA name for a state. It can have several heads (changes nothing else depends on); the tree is their union, not a conflict.
tagtagAn immutable named state, usually signed.
merge, rebaseoxy merge, oxy pullUniting bookmarks adds the other side's changes. Nothing is rewritten and no merge change is made.
merge conflictconflict in the stateA conflict is recorded in the history instead of blocking you. It stays visible (the Conflicts tab) until a change resolves it, and anyone can resolve it later.
pull requestproposalReviewed and tested on its projected state. It cannot go stale, and approvals can be signed seals.
branch protectiontrust policySigned rules in the repository itself: who may move which bookmark, with how many signatures. Every client enforces them, not only the hub.
Actions, CI badgeOxygenFlow, state stampJobs run in microVMs on exact states; results are receipts, and the stamp says which state they belong to.
git blameblameExact through rebases and squashes: each line is an atom with one authoring change, so there is no "ignore revisions" file.
forkforkA copy under your name with its own identity and bookmarks, sharing the stored objects. Its proposals go upstream as you/name:bookmark; the upstream's trust policy is not copied.
personal access tokentokenFor pushing and the API. Your signing key is what proves authorship; a token only authorises.
{% endblock %}