Patches

Browsing patches

The Patches tab on a repository lists every patch with state filters across the top:

• Draft — work-in-progress proposals not yet ready for review.
• Open — actively under discussion or review.
• Merged — accepted and incorporated into the canonical branch.
• Archived — closed without merging.

Each row shows the title, author, label set, and revision count. The revision count is how many times the patch has been updated — Radicle keeps the entire history.

If a CI pipeline is configured (via radicle-job), each patch also shows a status indicator: a green check for all jobs passing, a red cross if any failed, or a yellow dot while jobs are still running.

The list shows 50 patches per page; use Older and Newer at the bottom to navigate.

Reading a patch

Inside a patch, three tabs structure the main view:

• Activity — a chronological timeline of revisions, reviews, comments, lifecycle changes (archive / draft / reopen) and the eventual merge. Each event links to the author who produced it.
• Commits — the list of individual commits included in the latest revision, from newest to oldest. Each entry links to its full commit detail page.
• Changes — the unified diff of the latest revision against its base. Files are grouped, hunks are headed with line ranges, and additions and deletions are coloured accordingly.

The right-hand sidebar shows the patch's current status and, depending on your role, surfaces the actions you can take: Merge for delegates of a fast-forward patch, Convert to draft / Mark as ready / Archive / Reopen for the author or any delegate, and the patch's labels.

Proposing a change from the browser

The fastest way to contribute is the Edit button. Open any file in a repository's tree, click Edit in the file header, and you'll get a form with three things:

1. A code editor pre-populated with the file's current contents. Make your changes here.
2. A patch title — a one-line summary of what the change does.
3. An optional description — context, rationale, anything reviewers would benefit from.

When you submit, Radish:

• Creates a new commit with your edited file on top of the current branch.
• Opens a patch with the title and description you provided, signed by your key.
• Redirects you to the new patch page so you can share the link or keep iterating.

Right now editing is single-file at a time, which is enough for typo fixes, small docs corrections, and one-line bug fixes. For larger changes, push a branch via SSH and open a patch from it (see below), or prepare them locally with rad patch open.

Opening a patch from a pushed branch

For multi-file changes, delegates can push a feature branch via SSH and then open a patch from it in the browser — similar to opening a pull request after pushing a branch on GitHub.

1. Push a branch to the repository via SSH:

   git push origin my-feature

   See Pushing commits for SSH setup details. After a successful push, Radish prints a link in the terminal output:

   remote:
   remote: Create a patch for 'my-feature' on Radish by visiting:
   remote:   https://radish.farm/rad:z.../patches/new?branch=my-feature&peer=z6Mk...
   remote:

2. Follow the link, or go to the Patches tab and click New Patch.
3. Select your branch from the dropdown. The list shows all peer branches with the peer alias and branch name.
4. Enter a title and optional description, then click Open Patch.

Radish creates a patch comparing your branch tip against the repository's default branch. The patch is signed with your key and appears in the patch list just like any other patch.

You can also link directly to the form with a branch pre-selected by visiting /{rid}/patches/new?branch=my-feature&peer={nid}.

Automatic revisions on push

When you create a patch from a branch, Radish records that the patch tracks that branch. If you later push more commits to the same branch, Radish automatically creates a new revision on the patch — no manual step needed.

Tracking is stored as a custom git ref inside the repository, so it travels with the data. Only the specific branch chosen when the patch was created is tracked; pushing to other branches has no effect on the patch.

Commenting on a patch

The activity timeline includes a comment box at the bottom. Comments support Markdown and appear in the timeline alongside revisions and reviews so the discussion stays in chronological order.

Each comment is signed by its author. Like issue comments, they are append-only — if you want to retract something, post a follow-up.

CI status checks

If the repository has CI configured, the patch list shows a status indicator next to each title (✓ passed, ✗ failed, ◌ running) and the patch detail page includes a summary of job results for the latest revision. See Jobs for full details on how CI is set up and reported.

Reviews vs merges

It's worth being precise about the difference because the two actions feel similar but are independent in Radicle:

• A review is an opinion — Accept, Reject, or just a comment — that anyone signed in can leave from the main column's Comment & Review form. It does not change the patch state and does not move any branch. Even an Accept from a delegate is purely advisory.
• A merge is the actual state change. A delegate clicks Merge in the sidebar, which advances the canonical default branch and records the merge on the patch.

Both are signed Radicle operations and appear in the activity timeline. Only reviews from delegates carry weight at merge time — see Repository settings for delegates and the merge threshold.

Merging a patch

Delegates can merge a patch directly from the browser. Open the patch — if you are a delegate and the patch's head commit is a fast-forward of the default branch, the sidebar shows a Merge into {default branch} button.

Merging:

• Advances your copy of the default branch to the patch's head commit and signs the new refs.
• If the repository has a single delegate (threshold 1), the canonical default branch is updated immediately and the patch is marked Merged.
• If the threshold is higher, the merge is recorded against your peer. The patch flips to Merged only once enough delegates have merged the same commit — the same quorum logic the SSH push path uses.

Merging is fast-forward only. If the patch's head isn't a descendant of the current default branch tip, the Merge button is hidden and the sidebar tells you a rebase is needed. Push a new revision rebased on the default branch, or use the Radicle CLI to perform a non-fast-forward merge.

Draft, archive, reopen

Below the Merge button the sidebar offers the patch-state controls — these change the patch's state without merging. Either the patch author or any repository delegate can use them. The available buttons depend on the current state:

• Open patches can be Converted to draft (work-in-progress, hidden from the default Open list) or Archived (closed without merging).
• Draft patches can be Marked as ready (back to Open) or Archived.
• Archived patches can be Reopened.
• Merged patches are immutable — the sidebar offers no state buttons.

Each state change is recorded on the activity timeline so the history of how the patch reached its current state is preserved alongside reviews and revisions.

Tips for browser-based contributions

• Read the file first. The editor is plain text — there's no syntax checking, so review your change carefully before submitting.
• Keep edits small. A one-file, one-purpose patch is easier to review than a sprawling rewrite.
• Include why, not just what. The diff already shows what changed; the description is for reviewers to understand the reasoning.
• For anything bigger than a typo, consider cloning locally and pushing a richer patch with the CLI. Radish is an on-ramp, not a replacement for full tooling.