Update from main
Staying current while main moves — the behind-count, one-click update, and conflict resolution in-thread.
The hard part of parallel work isn't starting branches, it's not drifting from them. While a thread is in flight main keeps moving — other threads land, and teammates merge things outside the app entirely. darting.dev surfaces that drift instead of hiding it.
You always know how far behind you are
The thread's timeline shows exactly how many commits behind main the thread is, and the branch graph shows the same for every branch at once. It counts merges made outside darting.dev too, so the number is the truth about your repo, not just about work done in the app.
Update in one click
Update from main brings the thread current:
| Mode | When to use it |
|---|---|
| Merge (default) | Almost always. Append-only — no force-push surprises, and the branch's existing history stays exactly as it was. |
| Rebase | When you specifically want linear history on the branch. |
Either way it runs as part of the thread. The agent performs the update inside the thread's own sandbox, on the working tree it already knows, and resolves conflicts in place — conflicts are resolved, not discarded. Nothing about your local machine is involved, and nothing gets thrown away to make the update succeed.
Conflicts show up before you integrate
Merge conflicts are detected and flagged on the branch in the branch graph. You see them while the thread is still open and the agent still has full context on the change, instead of discovering them at merge time when the only thing left is a wall of markers.
Because the resolution happens in-thread, you can also just talk about it: ask the agent why the two sides diverged, or tell it which behavior should win. The conflict is a turn in the conversation like anything else.
Open PRs stay current on their own
Threads with an open pull request don't need you to remember. They pull in merged changes at the start of each turn, so a long-running PR doesn't quietly drift away from main between reviews. Combined with the CI loop — which re-runs checks after every fix push — a PR you left open yesterday is still being tested against today's main.
Where updating fits
main moves ─▶ behind-count on the timeline
└─ Update from main (merge · rebase)
└─ conflicts resolved in the thread's sandbox
└─ PR lands through the merge queue
Staying current is what makes the merge queue cheap: a branch that already contains the latest main has almost nothing left to reconcile when its turn to land comes up. Drift is handled while the thread is warm, one commit at a time, rather than saved up into a single painful merge at the end.
If a thread has drifted so far that the original approach no longer makes sense, updating isn't always the answer — it's often cleaner to fork it or start a follow-up from a fresh branch off current main.