Per-repository identity and multiple git accounts

[jonassaa]

There is no way to see or change which identity a commit is made with, and no
support for using different identities in different repositories.

"Manage multiple accounts" is
GitHub Desktop's second-most-reacted issue of all time
at 1,365 reactions — behind only "GitHub Desktop for Linux?". The use case is
mundane and extremely common: a work identity and a personal identity on the same
machine, and the cost of getting it wrong is a commit pushed to a public repo with
a corporate email in it, which is unfixable after the fact.

Where we are today

• src-tauri/src/git/signature.rs — default_signature(repo) reads whatever git
  config resolves to, and returns AppError::NoSignature when user.name or
  user.email is missing. That is the whole story.
• CommitOptions.author_override exists and is used for the co-author /
  author-override UI (Design & UX review: tree view, visual polish, app flow + feature gaps vs Fork/GitKraken/Sublime Merge/IntelliJ/TortoiseGit #61 D1), but that is a per-commit override, not a managed
  identity — it does not set the committer, does not persist, and is not surfaced
  as "who am I in this repo".
• No UI writes user.name / user.email at either scope. On a fresh machine with
  no global identity the user gets NoSignature and no way to fix it in-app
  (Stability pass: clone, stage/commit, push/pull and diff must survive launch day #212 already flags the error legibility half of this).

How

• Show the identity. The commit panel should name the identity the commit will
  be made with, resolved the way git resolves it. This alone prevents most of the
  damage.
• Set it, at both scopes. Edit user.name / user.email for the current
  repository (--local) or globally, from Settings and from the commit panel's
  identity affordance. Making the scope explicit in the UI is the point — a lot of
  the confusion here is users not knowing which scope they are editing.
• Named identities. A small set of saved identities (label, name, email,
  optionally a signing key) and a per-repository choice of which one applies.
  Persisted in our own settings, not in git config, with the chosen one written to
  the repo's local config so the CLI agrees with us.
• Tie in signing. signCommits is already tri-state per Design & UX review: tree view, visual polish, app flow + feature gaps vs Fork/GitKraken/Sublime Merge/IntelliJ/TortoiseGit #61 D6; a signing key
  belongs to an identity, so the identity is the natural place to hang it.
• Related, and cheap once identities exist:
  default editor per repository
  (55 reactions) is the same "per-repo override" shape.

Not a duplicate of

• Stability pass: clone, stage/commit, push/pull and diff must survive launch day #212 — that covers the error when no identity is configured. This is the
  management surface.

From the competitor research sweep (Aug 2026).

[jonassaa]

Reached the same conclusion independently from the cheat2001/angkorgit
sweep (they ship config_get/config_set, features/settings/profiles.ts, and a
Git tab described as "Auto fetch, committer identity and identity profiles").
Filed #247 before spotting this issue; closed it as a duplicate. Three findings
from that pass that are not already above:

The forge half is a separate, real limitation. The title says "multiple git
accounts", and the body is about git identity — but there is a second
one-account-per-host constraint on the forge side.
src/features/forge/useForgeStore.ts:42-60 persists logins: Record<string, string>,
host → login, singular. Two GitHub accounts is not expressible today even before
identities exist. If a saved identity is going to reference a forge account
(natural — the same work/personal split), that map has to become host → many
first. angkorgit models this as several accounts per host plus a default.

Shape for the backend piece. There is no config_get/config_set anywhere in
src-tauri/src/commands/. Worth adding them scoped to local/global and
restricted to a key allowlist (user.name, user.email, user.signingkey,
core.editor — which also covers the per-repo default editor noted above), rather
than a general config editor. A general one is a much larger security and support
surface for no extra user value here.

One constraint to pin. Writing --local config must fail cleanly on a
dubious-ownership path — see docs/superpowers/specs/2026-08-13-wsl-dubious-ownership-design.md.
That is the case where we would otherwise write into a repo we do not own and git
itself would then refuse to read it back.

Also: forge tokens are not git credentials (docs/dev/backend.md) — an
identity may reference an account, but must not carry its secret, and no command
returns a token.

[jonassaa]

The forge half landed in #375 (ea54d02) — the one-account-per-host limitation called out earlier in this thread.

Persisted shape went from logins: Record<string, string> (host → one login) to accounts: Record<string, ForgeAccount[]>, with exactly one active per host.

Why the slot lives in the credential username. The persisted map was not the only constraint: a token is stored under one credential key per host, so "add a second account" would have overwritten the first token and "switch active" would have been a lie. The host key has to stay shared — it is what keeps an API token off the git-transport credential for the same host — so the slot moved into the username= field, the only remaining part of the key: credential_username(None) == "platypusgit-forge", Some(id) == "platypusgit-forge:<id>". The id is opaque rather than the login, because a forge login can be renamed while the token stays valid.

Migration. The old logins[host] lands on id: null, which is byte-identical to the username a released build already wrote real tokens under — pinned by the_legacy_slot_username_is_byte_identical_to_what_shipped. Any other id would point at a slot that has never held anything and an already-signed-in user would come back signed out. "", null and undefined all collapse to that same slot rather than minting a third. 30 tests cover corrupt JSON, {}, a blob parsing to 42, duplicate ids, none-flagged, two-flagged, and both keys present at once.

No new Tauri command, no invoke_handler! change, no new AppError variant — lib.rs, error.rs and src/lib/types.ts are untouched. credential_input now line-safety-checks the computed username, so an account id carrying \n cannot inject host=.

Two things left, which is why this issue stays open:

1. A saved identity referencing a forge account — the natural work/personal pairing, and expressible for the first time now that the map is host → many. Two questions to settle first: whether applying an identity also switches the host's active forge account (which would silently change what a Pulls refresh lists), and what a dangling reference renders as once the account is removed — the same eviction problem the active flag was designed to dodge.
2. UI density. The account rows reuse ForgeSettings' local Row, whose fixed padding matches screens/Settings.tsx' own Row, so they do not opt into var(--row-step). Making only the forge rows density-aware would leave them a different height from their siblings in the same panel — it belongs on both helpers at once, or neither.