Archived
Simon FrankenandClaude Opus 5.5
27f0c0b5d2
- On startup, after the local state is shown, fetch the superproject and every initialized submodule (all remotes, prune, at most 8 at once). Fetches never prompt; failures show git's message. --no-fetch skips it, f fetches again. - The header shows "fetching n/m", then the fetch age and failures; the detail pane shows each submodule's last fetch and fetch errors. - The git provider polls each repository's metadata (refs, HEAD, index, .gitmodules) every 2 s and reports changes. The app reloads only what changed, keeping old values, expansion and cursor; loads are single-flight with coalesced reruns. Refresh is driven by the repositories, so a fetch in another shell updates the view like ours. - r reloads everything (worktree edits are not watched). - Docs: F50-F53, N1/N8 rewritten, D18-D20 (D12 superseded). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
submarine — documentation
submarine is a terminal UI for git repositories with many (recursively nested)
submodules. It shows only the submodules, as a collapsible tree, and
describes each pin as a branch plus distance (origin/main ↓1) instead of a
bare commit hash.
Documents
| Document | Contents |
|---|---|
| requirements.md | What the tool must do: functional and non-functional requirements |
| state-model.md | How a submodule's state is determined, summarized into issues, and how pins are resolved to refs |
| ux-guide.md | Layout, attention hierarchy, colors, wording, navigation and key bindings |
| architecture.md | Package layout, the provider boundary, async loading, testing |
| decisions.md | Decision log with rationale (ADR style) |
Status
Prototype. The UI is complete for browsing. It reads real repositories
through a git provider (internal/submodule/git): submarine [dir]. It
fetches in the background on startup (--no-fetch to skip; f to fetch
again) and follows changes made in other shells. submarine --mock shows
the built-in mock data (internal/submodule/mock). The actions u, b,
/, ! only show a "not implemented" message.
Next steps, roughly in order:
- Actions: checkout pin (
submodule update), bump pin to tip, init. - Filter (
/) and "problems only" (!) views.