sixfold-space/madtea

SHA256

Fork 0

status --json .host uses the cwd origin while .owner/.repo follow the --repo override #460

New issue

Open

opened 2026-08-27 04:40:58 +00:00 by hexajon · 1 comment

hexajon commented

2026-08-27 04:40:58 +00:00

Owner

The mismatch

When the --repo / MADTEA_REPO override is active, .owner and .repo come from the override target, but .host comes from the cwd repo's origin (or the configured host when there is no origin). If the override points at a repo on one forge and the cwd origin is on a different forge, the JSON mixes two identities.

.host never came from the override, so this is not a regression from #429; it only became easier to see.

Options

A: .host follows the --repo override target too, so all three identity fields describe the same repo.
B: keep .host as the cwd origin host, and document that --repo overrides only owner/repo.

Where I lean

A, because one coherent identity in the JSON is what a caller reading .host expects. It needs a host resolver for the override target and a decision on where that host is read from. Recording this so it is not lost; I am not building it until the semantics are settled.

Related: #429.

Surfaced while fixing #429 (status --json .host now reports the repo's own origin host). A residual inconsistency, pre-existing and out of #429's scope, but more visible now that origin outranks the configured host. ## The mismatch When the `--repo` / `MADTEA_REPO` override is active, `.owner` and `.repo` come from the override target, but `.host` comes from the cwd repo's origin (or the configured host when there is no origin). If the override points at a repo on one forge and the cwd origin is on a different forge, the JSON mixes two identities. `.host` never came from the override, so this is not a regression from #429; it only became easier to see. ## Options - A: `.host` follows the `--repo` override target too, so all three identity fields describe the same repo. - B: keep `.host` as the cwd origin host, and document that `--repo` overrides only owner/repo. ## Where I lean A, because one coherent identity in the JSON is what a caller reading `.host` expects. It needs a host resolver for the override target and a decision on where that host is read from. Recording this so it is not lost; I am not building it until the semantics are settled. Related: #429.

hexajon added the

status/needs-decision

label

2026-08-27 04:40:58 +00:00

hexajon referenced this issue

2026-09-04 16:33:51 +00:00

feat(repo-scope): target a repo on another forge host without a local clone #468

hexajon commented

2026-09-08 19:41:38 +00:00

Author

Owner

Reframed and decided. The A/B in this issue patched a symptom; the real defects are two.

Two divergent identity code paths. repoIdentity (internal/service/git/status.go:505-508) resolves the dir= path (owner/repo/host all from that checkout's origin) differently from the cwd path (owner/repo from the --repo/MADTEA_REPO override, host from the cwd origin). One question, "what repo is this?", answered by two code paths that can disagree. That divergence is the bug, not the host field alone.
The identity is JSON-only. owner/repo/host live in StatusResult and serialize to JSON, but the text output renders none of them. A human cannot discover that madtea holds this info without knowing to pass --json and parse it.

Decision (full KISS):

One identity resolver for every path, so owner/repo/host always come from one source and cannot disagree.
For a local-tree command, dir= is the canonical "which repo" selector: it moves the tree and the identity together. --repo/MADTEA_REPO resolve identity through that same resolver, not a separate origin read. Note these only relabel identity on a local-tree command; they cannot move the tree data (branch, ahead/behind), and the resolver work should keep that honest.
Surface the identity in the text output too, not only --json, so the capability is discoverable.

This supersedes the issue's A/B. Related: #429 (made host origin-first), and the legacy byte-identical cwd override (stub 1871) that forked the two paths.

Reframed and decided. The A/B in this issue patched a symptom; the real defects are two. 1. Two divergent identity code paths. `repoIdentity` (`internal/service/git/status.go:505-508`) resolves the `dir=` path (owner/repo/host all from that checkout's origin) differently from the cwd path (owner/repo from the `--repo`/`MADTEA_REPO` override, host from the cwd origin). One question, "what repo is this?", answered by two code paths that can disagree. That divergence is the bug, not the host field alone. 2. The identity is JSON-only. owner/repo/host live in `StatusResult` and serialize to JSON, but the text output renders none of them. A human cannot discover that madtea holds this info without knowing to pass `--json` and parse it. Decision (full KISS): - One identity resolver for every path, so owner/repo/host always come from one source and cannot disagree. - For a local-tree command, `dir=` is the canonical "which repo" selector: it moves the tree and the identity together. `--repo`/`MADTEA_REPO` resolve identity through that same resolver, not a separate origin read. Note these only relabel identity on a local-tree command; they cannot move the tree data (branch, ahead/behind), and the resolver work should keep that honest. - Surface the identity in the text output too, not only `--json`, so the capability is discoverable. This supersedes the issue's A/B. Related: #429 (made host origin-first), and the legacy byte-identical cwd override (stub 1871) that forked the two paths.

hexajon removed the

status/needs-decision

label

2026-09-08 19:41:39 +00:00

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#460

No description provided.

Rows
Columns