Archived
Simon FrankenandClaude Opus 5.5
19c6f17eb2
For a dirty submodule, list the changed files so the user can remember
what they were doing there:
Changes 5 files · 2M 1A 1D 1R · +37 −12
──────────────────────────────────
M render.go src/render/ +20 −4 3d ago
? scratch.txt 5m ago
- Status.Changes: files changed against HEAD (staged and unstaged
combined) with kind, line counts and modification time; sorted by kind,
then by size; capped at 200 with totals over all files.
- Git provider: parse `status --porcelain=v2 -z` and one
`diff HEAD --numstat -z -M`, only for dirty submodules.
- Detail pane: flat list with a colored status letter per file, like IDE
source-control views; counts and age in compact columns; up to 10 files,
every kind keeps a line, the rest is summarized as "n more".
- Fixture gains libs/work with every kind of change; mock data extended.
- Docs: F24, change preview in the UX guide, D17.
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 read-only git provider (internal/submodule/git):
submarine [dir]. submarine --mock shows the built-in mock data
(internal/submodule/mock). Actions (u, b, f, /, !) only show a
"not implemented" message.
Next steps, roughly in order:
- Actions: fetch, checkout pin (
submodule update), bump pin to tip, init. - Filter (
/) and "problems only" (!) views. - Refresh after actions and on demand.