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.

Reading a patch

Inside a patch, two tabs structure the view:

• Activity — a chronological timeline of revisions, reviews, comments, and the eventual merge. Each event links to the author who produced it.
• 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.

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, prepare them locally and push as a patch using rad patch open.

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.

Reviews and merges

Reviews (accept / reject / comment) and merges are currently performed via the Radicle CLI. Radish renders them in the timeline so you can see the full review history of a patch from the web, including who approved which revision and which commit was merged.

Patches are versioned: pushing a new revision after feedback doesn't lose the old one. The Changes tab always shows the latest revision; older revisions remain in the activity timeline.

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.