ux(clone): clone public repos unauthenticated; prompt for auth only when the remote actually requires it #163

New issue

Closed

opened 2026-07-16 17:26:42 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-16 17:26:42 +00:00

(Migrated from codeberg.org)

Cloning a public repo fails today when nothing is configured:

madtea clone https://codeberg.org/sixfold_space/madtea.git
Error: not configured: not configured - run 'madtea auth login' first

That is backwards for the most common first-contact flow: a public clone needs no credentials at all, and demanding auth login before the very first command a new user runs is a wall in front of the front door (the double "not configured: not configured" wrapping is its own small bug).

Ask

madtea clone <url> attempts the clone unauthenticated first (or detects repo visibility via the unauthenticated API) and succeeds for public repos with zero configuration.
Only when the remote actually requires auth (401/403 on the probe or clone) does it prompt: explain that the repo needs credentials and offer auth login for that forge (interactive), or name it in the error (non-interactive) - then proceed with the clone after login rather than making the user re-run it.
Post-clone conveniences that need credentials (per-repo credential wiring, backend markers) degrade gracefully on an unauthenticated public clone instead of failing the whole command.
Fix the duplicated "not configured: not configured" error wrapping while in there.

Acceptance

Fresh machine, zero config: madtea clone <public https url> succeeds.
Private repo, zero config: the failure names the forge, says auth is required, and points at (or interactively offers) auth login; after login the clone completes.
Existing authenticated behavior unchanged.

Cloning a public repo fails today when nothing is configured: ``` madtea clone https://codeberg.org/sixfold_space/madtea.git Error: not configured: not configured - run 'madtea auth login' first ``` That is backwards for the most common first-contact flow: a public clone needs no credentials at all, and demanding `auth login` before the very first command a new user runs is a wall in front of the front door (the double "not configured: not configured" wrapping is its own small bug). ## Ask - `madtea clone <url>` attempts the clone unauthenticated first (or detects repo visibility via the unauthenticated API) and succeeds for public repos with zero configuration. - Only when the remote actually requires auth (401/403 on the probe or clone) does it prompt: explain that the repo needs credentials and offer `auth login` for that forge (interactive), or name it in the error (non-interactive) - then proceed with the clone after login rather than making the user re-run it. - Post-clone conveniences that need credentials (per-repo credential wiring, backend markers) degrade gracefully on an unauthenticated public clone instead of failing the whole command. - Fix the duplicated "not configured: not configured" error wrapping while in there. ## Acceptance - Fresh machine, zero config: `madtea clone <public https url>` succeeds. - Private repo, zero config: the failure names the forge, says auth is required, and points at (or interactively offers) `auth login`; after login the clone completes. - Existing authenticated behavior unchanged.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#163

No description provided.

Rows
Columns