Skip to main content
Tascarrel is alpha software and may break. We’re looking for your feedback — share it on GitHub.
Documentation

Review and Publish Changes

Tascarrel keeps upstream Git credentials and shared object caches on the host. Configured repositories appear at their declared paths below /workspace:

[repos."product/api"]
source = "git@github.com:example/api.git"
branch = "release/next"

Omit branch to check out the upstream’s advertised default branch.

Add a Repository to an Existing Pod

Repositories added to the workspace configuration are included in new pod workspace seeds. To add one to an existing pod, start the pod, open its Repositories tab, and select Import beside the absent checkout.

Tascarrel imports one prepared host-cache version and configures the checkout for the same mediated fetch and push flow as a new pod. Import requires the configured path to be absent. If a file or directory already occupies that path, Tascarrel leaves it unchanged; move or remove the conflicting content yourself, or create a new pod.

Review the Pod

The Changes view shows modified, staged, deleted, and untracked files, along with supported text diffs. It also reports commits ahead of or behind the local tracking ref; displaying that comparison does not fetch from the network.

Run focused checks in a terminal and review the actual diff rather than relying only on an agent summary.

Set Publication Policy

Git pushes require approval by default. Configure ordered rules when some refs need different treatment:

[git]
default-policy = "require-approval"

[[git.branches]]
pattern = "main"
policy = "deny"

[[git.branches]]
pattern = "automation/**"
policy = "allow"

[[git.tags]]
pattern = "**"
policy = "require-approval"

Policies are allow, deny, or require-approval. Patterns match short branch or tag names. A single * stays within one slash-delimited component; ** crosses components. A repository can replace the workspace policy with its own rules.

Publish the Ref

Run a normal push from a configured checkout:

git push origin HEAD

The remote transport carries the proposal through the workspace VM to the host. An allowed push publishes immediately, a denied push fails, and a push requiring approval waits for a decision in Workspace → Repositories.

The approval shows exact old and new object IDs. Approve, reject, or postpone it after matching the refs to the commits you reviewed. Publication retains the old values as leases, so a concurrent upstream change fails closed. Multi-ref updates remain atomic.

Ref deletion is not supported. Arbitrary remotes do not gain access to host-owned credentials.