Continue a Branch on Another Host
Carry a project and its branch to another host: how Daintree finds the host's copy, the branch states and push choices, cloning or sending a bundle, setup recipes, creating worktrees on another host, and what never moves.
When to Use It
A plain switch takes a window to a host as it is. This is the other move: you are on a branch here and want to carry on with it on another machine, with the agents there. Daintree does that through Git, the same way you would by hand: it finds the host's copy of the repository, or clones one there, gets your branch onto the remote if it needs to be, and opens a worktree for the branch on the host.
It works in both directions: from this machine to a host, from one host to another, and from a host back to this machine. Pushes run on the machine you are coming from, with its credentials. Clones run on the machine you are going to, with its credentials. Nothing is ever pushed without your click.
Open the Dialog
- The host menu: click the host chip, then Continue this branch on… › and the host.
- The project switcher: right-click a project row, Open on… ›, and the host. Cmd-click (Ctrl-click on Linux) lands the result in a new window.
- The New Worktree dialog: pick another machine in its Host row, then Create on studio-01…. See Create a Worktree on Another Host.
- An agent can ask for it over MCP (
project.openOnHost). That only opens the dialog, which never goes straight through for an agent: pushing, cloning and opening wait for your click.
Choosing the host the window is already on is refused with This window is already on that host.
How the Host's Copy Is Found
First Daintree checks your branch on the machine you are coming from: where it stands against its remote, asking the remote with git ls-remote and fetching only a commit it doesn't have yet. Then it looks for the same repository on the target:
- projects registered there that share one of your project's remote URLs;
- registered projects that share the project id committed in
.daintree/project.json, ranked after the registered remote matches; - if no registered project matches a remote, clones on disk that aren't added as projects yet, found by looking up to two levels deep in the host's projects folder and beside its other projects.
While that runs, the dialog says it is checking the project on both machines.
The Host Already Has It
The dialog is titled Open Atlas Ledger on studio-01 and names the copy it found: studio-01 already has this project., or studio-01 has a clone of this repository that isn't added as a project yet. With several candidates you choose under Which copy to open. Each copy shows its path, its remotes and when it was last opened or changed, plus a note when it matters:
- Same repository as your upstream (or whichever of your remotes it matched) when your project has several remotes, such as a fork and its upstream;
- Not a project yet for a clone on disk;
- Same project id, different remotes when only the committed id matched.
Below that is the Branch row, then two links. Use another folder on studio-01… picks a folder on the host; a folder that isn't a registered project there is checked to be a clone of this repository. Clone a fresh copy instead, shown when your project has a remote, switches to cloning. The main button reads Open on studio-01, or Use existing folder for an unregistered clone, or Push, then open when you chose to push.
The Branch
The Branch row says where your branch stands and, when there is a decision, offers it:
| Where the branch is | What happens |
|---|---|
| On the remote at the same commit | It opens in a worktree for feature/x. Nothing to decide. |
| Behind the remote | It opens in a worktree for the branch, created from the remote's version. Nothing to decide. |
| Ahead: unpushed commits | Choose Push, then continue (pushes from this machine with its credentials) or Continue from the remote's version (the unpushed commits stay here). Continuing from the remote is preselected; push never is. |
| Diverged from the remote | Nothing is pushed. Cancel and sort it out here, or continue from the remote's version. |
| Only exists here | Start from the default branch, preselected, or, when Daintree can tell which remote the branch belongs to, Push branch, then continue, which pushes it and sets the upstream. |
| The remote couldn't be reached | Choose Continue from the remote's version or Start from the default branch. Git's error is shown when there is one. |
| No branch checked out | No worktree is requested. A project the host already has opens as it is; a fresh clone opens on the repository's default branch. |
When you pick a push, the dialog previews what it will publish, The push publishes these commits:, with up to 20 commits by short hash and subject, worked out from this machine's view of the remote. With uncommitted changes, the row adds Uncommitted changes on This Mac stay there.
Cloning onto the Host
When the target has no copy, the dialog is titled Atlas Ledger isn't on studio-02 yet and plans a clone:
| Row | What it does |
|---|---|
| Clone | The remote to clone from. With several remotes you pick one. Only HTTP(S) and SSH remotes can be cloned. |
| Into | The folder on the host, with Change… to pick another. By default it is the same path relative to home as here, when that is free on the host (or already holds a clone of this repository) and sits in a code folder such as ~/Projects or ~/code. Otherwise it goes in the host's projects folder, adding -2, -3 if the name is taken. The folder is checked live as you edit it. |
| Branch | As above. After the clone, the host opens a worktree for your branch. |
| Initialise submodules | Checked when the repository has submodules initialized here. |
| Setup | Shown when the repository tracks recipes: one to run after cloning, or No setup recipe. Preselected to the project's default worktree recipe when you start from this machine. |
| Advanced | Full clone (the default), Shallow clone (only the latest commit) or Partial clone (all history; file contents are fetched when needed). |
If the repository's .gitattributes uses Git LFS and the host has no git lfs, the dialog warns that LFS files would arrive as pointer files. The main button reads Clone and open, or Push, then clone. Use an existing folder on studio-02… points it at a copy you already have there.
The host clones with its own Git credentials; this machine's credentials are never sent. When it can't, the dialog quotes Git and suggests the fix:
| Cause | Suggested fix |
|---|---|
| Authentication, or repository not found | studio-02 needs its own access to this repo: add an SSH key on studio-02, or connect GitHub on studio-02 (Settings on studio-02 → GitHub). GitLab repositories name GitLab; other servers suggest an SSH key or credentials on the host. |
| Network | studio-02 couldn't reach the server. Check its network and try again. |
| Git or Git LFS missing | Install git on studio-02. or Install Git LFS on studio-02. |
No Remote: Send a Copy
A repository with no remote has nothing for the host to clone from. When the target has no matching project either, the dialog offers Send a copy of the repository, which sends a Git bundle of the committed history, with its branches and tags, into a folder you choose on the host. The working tree, submodule repositories and LFS objects stay here. The alternative is to publish the repository to a forge first, then switch again.
After It Opens
The dialog closes and Daintree opens the project on the host, in this window or a new one as you asked, or brings forward a window that already shows it. When a branch worktree was requested, the host creates it, or reuses one already on that branch as it is, without moving it to the remote's commit. A project another machine has control of opens viewing: … has control of this project · Viewing here, with Take control.
A clone that came with a setup recipe asks once, in the first window that opens it: Run "Bootstrap"?, listing every terminal, command, environment variable and prompt the recipe would start, with Run recipe and Don't run (focus starts on Don't run). A cloned project gets its own project identity on the host, and lifecycle approvals for that folder start fresh.
Sometimes the host opens the project without your branch's worktree. If the branch can't be fetched there, or the host's own copy of the branch is at a different commit, the dialog says why and offers Open without it. If another machine has control of the project, it offers Check out here, which still needs control of the project to go ahead.
Create a Worktree on Another Host
Once a host exists, the New Worktree dialog has a Host row listing this machine and every host you have added, with hosts that aren't connected grayed out. When machines have reported their load, it suggests the least busy one, Least loaded: studio-02 · CPU 12% · memory normal · 2 working (observed), with a Use studio-02 button when that isn't the machine selected. Select another machine and Create on studio-02… appears, which runs this same dialog to get the project there, then creates the worktree on that host. See Least Loaded for how the suggestion is ranked.
To start a project on a host from a repository URL instead, use Add project… on the host's card in the Hosts overview.
What Never Moves
- Uncommitted changes. They stay on the machine they were made on.
- Unpushed commits and local-only branches, unless you choose to push them, or send the whole repository as a copy.
- Terminals and agent sessions. The window shows the target host's own; the ones you left keep running.
- Credentials and settings. Each machine signs in to Git, forges and agents for itself.
- Plugins. Differences are reported, never fixed silently. See Plugins Across Machines.