Monorepo for Tangled tangled.org
854
fork

Configure Feed

Select the types of activity you want to include in your feed.

No XRPC endpoint to write the first commit on an empty repo over HTTPS #532

open opened by austegard.com

Summary#

There's no XRPC endpoint for "make the first commit on an otherwise-empty repo." The current surface is:

Operation Available?
git init --bare (empty repo) sh.tangled.repo.create
git clone --bare <url> (import from elsewhere) sh.tangled.repo.create with source
git am <patch> into an existing branch sh.tangled.repo.merge
Initial commit / update-ref on an empty repo ✗ no endpoint
General git receive-pack ✗ SSH-only by policy

repo.merge calls git.Open(repoPath, branch) which resolves the target ref before applying the patch — so it can't bootstrap a freshly-init'd repo. From a client's perspective this means: I can create an empty repo over HTTPS, I can import a whole repo from another URL over HTTPS, but I cannot add a single first commit to my own empty repo without falling back to SSH push.

Why this matters#

Comes up immediately in any environment that lacks port-22 egress — sandboxes, CI runners with constrained networking, browser-based dev environments like Anthropic's CCotw, etc. Hit this while building a Tangled CLI integration for CCotw: the only way to populate a CCotw- created repo was --source (clone from GitHub). That worked, but it forces every "I want a fresh Tangled-native repo and push my first commit from here" workflow through an unnecessary intermediate host.

Suggested fix#

Lowest-cost option: relax sh.tangled.repo.merge to accept an empty target — if the branch doesn't resolve, treat the patch as the root commit(s) for that branch (git am already handles --root-style patches into an empty state). One server-side line change roughly:

// in knotserver/xrpc/merge.go (sketch)
gr, err := git.Open(repoPath, branch)
if errors.Is(err, plumbing.ErrReferenceNotFound) {
    gr, err = git.OpenForRootCommit(repoPath, branch)
}

Higher-cost option: a fresh sh.tangled.repo.commit or sh.tangled.git.applyPatch endpoint with explicit "create branch from patch" semantics. Cleaner API but more surface area.

Either fix closes the asymmetry without touching the SSH-push policy.

  • The clone-from-source path (sh.tangled.repo.create with source) already proves arbitrary git operations CAN safely happen server-side over HTTPS via service-auth tokens. Same trust model applies here.
  • Found while documenting the source-import flow in https://github.com/oaustegard/claude-tangled-spoke (Claude Code on the Web → Tangled integration).
sign up or login to add to the discussion
Labels

None yet.

assignee

None yet.

Participants 1
AT URI
at://did:plc:r2whjvupgfw55mllpksnombn/sh.tangled.repo.issue/3mlp5xlkn4t25