Skip to content
Agent Workspaces
Agent

git-runtime

Git is split into a transport contract and a host-scoped runtime. Renderer, desktop, and workspace-server code share the Wire vocabulary without importing Git execution, canonical host paths, watchers, or lease ownership.

From plugin
emdash
6.2k33 skills33 agents

Agent definition

git-runtime.md

Git Runtime Architecture

Git is split into a transport contract and a host-scoped runtime. Renderer, desktop, and workspace-server code share the Wire vocabulary without importing Git execution, canonical host paths, watchers, or lease ownership.

Ownership

  • `packages/core/src/runtimes/git/api/` owns selectors, contracts, serialized states, inputs,

results, errors, and client-used pure helpers.

  • `packages/core/src/runtimes/git/node/` owns provisioning, identity resolution, canonical

resources, watchers, reconciliation, Git execution, and `gitComponent`.

  • `packages/wire/` owns live-state publication, `ComputedLiveState`, resource-backed live-model

hosts, mutation cursors, jobs, replicas, and transport behavior.

  • Portable API modules never import Node runtime implementation code. Canonical identities and

canonical host paths are runtime-only.

Runtime Shape

`GitRuntime` is the host-scoped composition root. It exposes three deep entry points:

  • `provisioning` inspects, initializes, and clones paths before a canonical resource exists, and

trusts a repository Git refuses for its ownership: after user confirmation it adds the exact `safe.directory` value Git suggested to the host user's global Git config (never wildcards);

  • `repository` resolves repository selectors and serves repository procedures, jobs, and live

models;

  • `checkout` resolves checkout selectors and serves checkout procedures, jobs, and live models.

The API layer delegates directly to these entry points:

getLog: (input) => runtime.checkout.getLog(input)

It does not acquire leases, classify effects, dispatch mutation names, or translate cursors.

Canonical Resources

`GitAllocationGraph` is a private resource registry. It resolves path aliases, pools resources by canonical identity, retains a repository for every checkout, applies the idle TTL, and disposes failed or idle resources.

The pooled values are deep resource objects:

1. `RepositoryResource` represents one canonical common Git directory. It owns repository live states, the common-directory watcher, repository-family command ordering, object-store locking, active checkout registration, explicit repository operations, and their reconciliation. 2. `CheckoutResource` represents one canonical worktree. It owns checkout live states, the worktree watcher, file-diff staleness, explicit checkout operations, and their reconciliation.

Repository-family command ordering is one FIFO lane shared by every checkout of the repository: mutations and the status, head, refs, and remotes scans run through it. File-content reads do not. They resolve a blob OID first, so they need no ordering and run in a separate lane of at most two reads per repository family; slow status scans and object transfers do not hold up the diff editor. Releasing the last owner of a content query cancels its queued or active read.

The checkout head state is authoritative for the current branch's canonical full ref, configured upstream, tracking ref, and divergence. Upstream state distinguishes local tracking from remote tracking; only a remote upstream means the branch is published. Repository refs are inventory for branch selection and repository policy; they are not joined with checkout state to infer whether the current branch is published. Current-branch publication resolves the checked-out full ref on the host and travels through the dedicated checkout publication job.

Repository identity is the canonical common Git directory. Checkout identity combines the canonical checkout root and private Git directory. Linked worktrees share one repository resource while retaining distinct checkout resources.

`GitRepository` and `GitCheckout` are the low-level command drivers composed by those resources. They build commands, invoke `BoundExec`, parse output, and return typed operational results. They do not own Wire hosts, resource leases, or cross-state reconciliation. `GitRepository` lazily keeps a repository-scoped `git cat-file --batch` process for repeated blob reads; process creation remains owned by `BoundExec`, so repository scoping and dynamic executable selection apply uniformly.

Live Models

Wire's `expose()` (from `@emdash/wire/state`) adapts keyed, externally authoritative resources to live models as a `LeasedLiveModelProvider`. It owns generic resource acquisition, keyed state retention, mutation idempotency, typed handler dispatch, and settled cursor construction.

Git supplies exhaustive mutation-handler maps:

mutations: {
  stage: (context) => context.resource.stage(context),
  commit: (context) => context.resource.commit(context),
}

Each resource method receives its exact contract input. There is no untyped envelope, mutation-name switch, or Git-side input cast. Mutation-free file-diff models use the same host without a fake mutation implementation.

Reconciliation

Reconciliation is local to the operation that changes external Git state:

  • staging operations synchronously refresh and settle checkout status, then invalidate affected

file diffs;

  • history-changing operations invalidate checkout status, head, mutable-ref file diffs, and

repository refs as appropriate;

  • repository ref operations invalidate active linked checkouts;
  • jobs reconcile immediately after success or partial failure according to their own semantics;
  • successful current-branch publication refreshes checkout head before the job settles, and the

invoking renderer performs an additional head refresh as its observation barrier;

  • filesystem watchers call the same direct resource invalidation methods.

There is no operation classifier or global effect plan. Small shared methods such as `historyChanged()` express repeated domain effects without redispatching on operation names.

Common-Directory Watch

The repository resource and the workspace-registry scan scheduler watch the common Git directory with `gitMetadataWatchProfile()` from `packages/

Read more
@generalaction
Ships withemdash

Emdash is the Open-Source Agentic Development Environment (🧡 YC W26). Run multiple coding agents in parallel. Use any provider.

Stars on GitHub

Momentum

stars in total
6.2k
Star history of generalaction/emdash on GitHub, a chart by star-history.com

Other agents on emdash.

acp-runtime

acp-runtime

Agent

The ACP runtime is the domain service that serves the ACP API contract. It owns the host-scoped dependencies needed to run…

core-modules

core-modules

Agent

This page defines the target organization of `packages/core/src/`. Core is organized by module type so that shared domain APIs…

main-process

main-process

Agent

The main process is organized into domain modules under `src/main/core/`. Each domain typically has a `controller.ts` (RPC…

path-system

path-system

Agent

`@emdash/core/primitives/path/api` is the source of truth for portable file identity and lexical path operations. The detailed…

More agents from other plugins.

api-builder

api-builder

Agent

Deprecated placeholder. Do not use; follow root AGENTS.md and package instructions instead.

happier2d2.2k
@happier-dev@happier-devInstall Agent

Questions about git-runtime.

Which coding agents can use git-runtime?
git-runtime installs in Claude Code and Cursor: each loads subagents from .claude/agents, so copy the file there. Flowy's auto-invocation runs in Claude Code only.