fix(worktree,bash): propagate the repo's git identity into worktrees and bash commits — never invent one

[wqymi]

Summary

A linked git worktree does not inherit its parent repo's local config, so commits made in a mimocode-created worktree could be authored MI <mi@MIdeMacBook-Pro.local> — the machine hostname, in pushed history. This propagates the identity the repo itself resolves into the worktree, and injects it for bash-tool commits.

It deliberately does NOT invent an identity when the repo has none. An earlier revision of this PR did (a hardcoded MiMo <mimo@xiaomi.com> fallback); that was wrong and is removed — see the follow-up section at the bottom for the measurements that settled it. The contract now is propagate or abstain: copy what git can resolve, otherwise set nothing and leave git's own chain (local → global → system → EMAIL → autodetect → git's actionable error) fully intact.

Root cause

A separate worktree checkout shares the object/ref store with its parent repo but has its own config, so it does not inherit the parent's LOCAL git identity. With no global identity either, git commit autodetects user@hostname. That differential — the parent repo commits correctly, its worktree does not — is the actual defect, and the only thing this PR is entitled to fix.

Layer 1 — worktree local config (src/worktree/index.ts setup())

After git worktree add + the HEAD-attach assertion, inside the existing per-repo lock:

1. Resolve the parent repo's identity via git -C <ctx.worktree> config user.name/user.email (walks local → global → system).
2. Pin each resolved field into the new worktree's own local config.
3. If a field does not resolve, write nothing for it and log.warn, so the worktree behaves exactly like its parent instead of carrying an identity nobody chose.

Covers worktrees mimocode creates in code, including commits made there later by the user's own terminal — which is precisely why an invented identity was harmful and an abstain is not.

Layer 2 — bash-env floor (src/tool/bash.ts shellEnv())

Layer 1 does not cover commits an agent makes through the bash tool in an ad-hoc directory, so shellEnv() injects GIT_AUTHOR_NAME/EMAIL + GIT_COMMITTER_NAME/EMAIL as a floor:

• Resolve the repo identity once per worktree (memoized) via the Git service at Instance.worktree.
• Inject only the fields that resolved; inject nothing at all when nothing resolved.
• The non-git case (Instance.worktree === "/") now injects nothing — previously it short-circuited straight to the hardcoded identity without consulting any config.
• Fill only the vars absent from process.env, so an operator-set GIT_AUTHOR_* still wins — per variable, not all-or-nothing. Plugin extra.env is spread last and can still override.

⚠️ Why "inject nothing" matters and is not merely tidier: GIT_AUTHOR_*/GIT_COMMITTER_* override the config of whatever repo the command runs in, not just the session's repo. A placeholder floor therefore rewrote authorship in unrelated repositories reached with cd.

Corrected: git precedence (env beats config)

An earlier revision of this description — and a code comment — claimed the layer-2 env floor sat below repo/worktree local config. That was backwards. Verified empirically:

# repo config user.name=LocalCfg, plus explicit -c user.name=DashC
GIT_AUTHOR_NAME=EnvName ... git -c user.name=DashC commit
→ author=EnvName <env@x.com>   committer=EnvName <env@x.com>

GIT_AUTHOR_*/GIT_COMMITTER_* env outranks user.name/user.email config, including an explicit -c. Actual precedence:

GIT_AUTHOR_*/COMMITTER_* env > worktree/repo LOCAL config > global > EMAIL > autodetect user@hostname.

The two layers don't conflict: layer 2 seeds itself from the same config resolution, so they normally agree. Layer 1 remains necessary for commits made in the worktree outside the bash tool, where no env floor is present. The comment in shellEnv() has been corrected to match the code and git's real behavior.

Documented cache contract

gitIdentityCache is keyed by worktree path and memoized for the process lifetime. Its behavioral contract is written down at the definition site:

• Its only job is to stop the worktree/parent attribution differential. It is not a general identity-configuration feature, and it never substitutes an identity of its own.
• Because it is delivered as env, it takes precedence over the repo's config (see above) — including a repo reached by cd.
• Because the resolved value is memoized per worktree path, a git config user.name ... performed mid-session is not picked up until the process restarts.
• Operator-set GIT_AUTHOR_*/GIT_COMMITTER_* still win, per variable.

Also noted why resolveGitIdentity/gitIdentityCache live in the tool's outer setup block rather than inside shellEnv — so the cache persists across bash invocations instead of re-spawning two git config subprocesses per call.

Tests (real git, no mocks)

test/worktree/index.test.ts:

• worktree inherits the parent repo's identity;
• worktree whose parent has no identity is left with an empty --local identity, and a commit there resolves through git's own chain (asserted via EMAIL).

test/tool/bash.test.ts:

• bash env injects the 4 GIT_* vars inherited from repo config;
• a non-git project (worktree=/) gets no GIT_* var injected;
• per-variable precedence: with only GIT_AUTHOR_NAME operator-set, that one var is preserved while the other three each still receive the floor.

⚠️ The two assertions that previously pinned the invented fallback were replaced, not adjusted — they encoded the defect, so quietly editing them to match new behaviour would have hidden the change.

Reviewer note — .text.trim() vs .text().trim()

These are two different runners, both correct, not a silent bug:

• worktree/index.ts uses a file-local git() helper returning { code, text, stderr } where text is a plain string from Stream.mkString — hence the property form .text.trim(). The same file already uses that form at :264, :272, :425, :430, :448.
• bash.ts uses gitSvc.run(...), whose Result.text is a method — hence .text().trim().

Verification

• bun typecheck → exit 0
• bun test test/worktree/index.test.ts test/tool/bash.test.ts --timeout 120000 → 31 pass / 0 fail (84 expect() calls); pristine baseline at ae18decb7, identical command → 30 pass / 0 fail
• bun test test/git → 7 pass / 0 fail
• Rebased onto latest origin/main.

Follow-up (8c965e96b): the fallback identity is removed — git decides

A review objection was raised against Git.FALLBACK_IDENTITY (MiMo <mimo@xiaomi.com>): a
hardcoded fallback attributes commits to an identity the user never chose, and git already has its
own fallback chain. Investigated against git's actual behaviour, and the objection holds.

Measured on git 2.50.1:

probe	result
no identity configured anywhere, no EMAIL	git commit exit 0, author MI <mi@host.local> — there is no fatal to rescue
EMAIL=real@person.dev, no config	git config user.email prints nothing, exit 1 — the probe is blind to EMAIL
same, git commit	author MI <real@person.dev> — git would have used the user's chosen address
repo with LOCAL Real Person <real@person.dev>, commit run with the 4 injected vars	author=MiMo <mimo@xiaomi.com> — env outranks that repo's own correct config

So the constant was not a rescue for a hard failure; it pre-empted a resolution git could still
make, silently, and with no log or surfaced message. Worst case: for a non-git project
(Instance.worktree === "/") bash.ts injected the placeholder without probing any config at
all, so a cd ~/anyrepo && git commit through the bash tool overrode that repo's real identity.
Layer 1's write also lands in <worktree>/.git/config, so it governed every later commit there —
including ones the human makes in their own terminal.

Both layers are now propagate-or-abstain. They copy an identity the repo itself resolves, and
pin/inject nothing when it resolves none — leaving the fallback to git (config → EMAIL →
user@hostname → git's own actionable *** Please tell me who you are.). Unresolved fields are
log.warned rather than silently substituted, so the abstain is discoverable.

This keeps the PR's actual fix intact: the reported bug was that a linked worktree does not
inherit the parent's LOCAL identity, and propagation still fixes exactly that. When the parent has
no identity, the worktree now resolves authorship exactly as the parent repo would — mimocode
introduces no attribution differential, which is the honest contract.

The two assertions that pinned the substitution encoded the defect

They are replaced, not quietly edited to match:

• test/worktree/index.test.ts — was expect(email).toBe(Git.FALLBACK_IDENTITY.email); now asserts
  the worktree's --local identity is empty.
• test/tool/bash.test.ts — was toContain('GIT_AUTHOR_EMAIL=' + Git.FALLBACK_IDENTITY.email); now
  asserts no GIT_* var is injected for a non-git project.

New regression test + revert-probe

New: "does not override an identity git itself would resolve from EMAIL" — commits in a worktree
whose parent has no identity and asserts the author email comes from EMAIL.

Revert-probe (new tests, src/ reverted to ae18decb7) → 28 pass / 3 fail:

error: expect(received).toBe(expected)
Expected: "chosen@example.test"
Received: "mimo@xiaomi.com"
(fail) Worktree.setup git identity > does not override an identity git itself would resolve from EMAIL
Expected: ""              Received: "MiMo"
Expected: "GIT_AUTHOR_NAME="   Received: "GIT_AUTHOR_NAME=MiMo"

Verification

• bun typecheck → exit 0
• bun test test/worktree/index.test.ts test/tool/bash.test.ts --timeout 120000 → 31 pass / 0 fail
  (84 expect()); pristine baseline of the identical command at ae18decb7 → 30 pass / 0 fail (85).
• mimo@xiaomi.com no longer appears anywhere in packages/opencode.