Context
JSS's git HTTP backend (`--git`) already routes clone / fetch / push through `git http-backend` and gates each by ACL (Read for fetch, Write for push). What's missing is a way to create a new bare repo at an arbitrary pod path over HTTP. Today the only path to a working remote is to shell into the data directory and run `git init --bare` manually.
Without an init primitive, the "apps via git" use case (see jspod#25, JSS#464) requires filesystem access on the pod host — which defeats the point of having a git HTTP backend in the first place.
Repro
```bash
Start JSS with --git enabled. Try to push to a fresh path:
git clone https://github.com/solid-apps/penny.git
cd penny
git remote add pod http://localhost:5444/public/apps/penny
git push pod main
→ 404 { error: 'Not a git repository' }
```
Source: `src/handlers/git.js:155` — `findGitDir` returns `null` when there's no `.git` subdirectory at the target path, and the handler short-circuits with a 404.
Proposed primitives
Option A — Auto-init on first authenticated push (GitHub-style)
When `/git-receive-pack` (or its `/info/refs?service=git-receive-pack` advertise) targets a path that doesn't yet have a `.git`, JSS:
- Verifies ACL Write on the target path
- Runs `git init --bare` at the path (or creates a regular repo with `.git` — bare is cleaner for storage)
- Continues the push as normal
Pro: one round-trip from the user's perspective. Matches GitHub / GitLab semantics. No new endpoint to spec.
Con: subtle. A typo in the push URL silently creates a new repo at the typo'd path (gated by ACL, but still). Could be mitigated with a `?init=true` opt-in or a `Git-Init: true` header.
Option B — Dedicated init endpoint
`POST //.git/init` (or similar) with ACL Write check:
- If `` exists and is a directory → init a bare repo inside it
- If `` doesn't exist → `mkdir -p` + init
- Return 201 Created with the new remote URL
Pro: explicit. No footgun on typos. Easy to wire into a UI.
Con: extra round-trip. New endpoint to document.
Option C — Both
Default to B for explicit invocation; offer a `--git-auto-init` server flag to opt into A. Wrappers like jspod can opt in to the convenience.
Out-of-scope
Server-side clone (POST a git URL, JSS does `git clone `) is a related but separate primitive — let's keep this issue tight to init.
Cross-references
- jspod#25 — generalize app installation via git
- JSS#464 — apps-in-pods at the protocol level (git as a source)
- JSS#462 — onboarding overhaul (this would feed Phase 8 / apps story)
Context
JSS's git HTTP backend (`--git`) already routes clone / fetch / push through `git http-backend` and gates each by ACL (Read for fetch, Write for push). What's missing is a way to create a new bare repo at an arbitrary pod path over HTTP. Today the only path to a working remote is to shell into the data directory and run `git init --bare` manually.
Without an init primitive, the "apps via git" use case (see jspod#25, JSS#464) requires filesystem access on the pod host — which defeats the point of having a git HTTP backend in the first place.
Repro
```bash
Start JSS with --git enabled. Try to push to a fresh path:
git clone https://github.com/solid-apps/penny.git
cd penny
git remote add pod http://localhost:5444/public/apps/penny
git push pod main
→ 404 { error: 'Not a git repository' }
```
Source: `src/handlers/git.js:155` — `findGitDir` returns `null` when there's no `.git` subdirectory at the target path, and the handler short-circuits with a 404.
Proposed primitives
Option A — Auto-init on first authenticated push (GitHub-style)
When `/git-receive-pack` (or its `/info/refs?service=git-receive-pack` advertise) targets a path that doesn't yet have a `.git`, JSS:
Pro: one round-trip from the user's perspective. Matches GitHub / GitLab semantics. No new endpoint to spec.
Con: subtle. A typo in the push URL silently creates a new repo at the typo'd path (gated by ACL, but still). Could be mitigated with a `?init=true` opt-in or a `Git-Init: true` header.
Option B — Dedicated init endpoint
`POST //.git/init` (or similar) with ACL Write check:
Pro: explicit. No footgun on typos. Easy to wire into a UI.
Con: extra round-trip. New endpoint to document.
Option C — Both
Default to B for explicit invocation; offer a `--git-auto-init` server flag to opt into A. Wrappers like jspod can opt in to the convenience.
Out-of-scope
Server-side clone (POST a git URL, JSS does `git clone `) is a related but separate primitive — let's keep this issue tight to init.
Cross-references