status

git splice status [--upstream <name>] [path…]

Lists every splice: a folder with a .splice file. Each one gets its sync state, with commits counted like git status counts them against a tracking branch: "behind 1" is one commit for pull to bring in. status doesn't fetch; it uses what was fetched last.

In the sandbox, vendor/pkg-a/'s upstream has one commit the monorepo doesn't have yet:

$ git splice status
On branch main

  behind 1  vendor/pkg-a

Sync states

status reports one of these states for each splice, and merge, pull and push act on it. Each example is a small, tested scenario; all scenarios cover more situations. status lists the splices that need something first, most urgent first, as in this monorepo with many splices.

`status` shows	Meaning	What to do
`?? never fetched`	The upstream wasn't fetched in this clone yet. (example)	Run `git splice fetch`.
`up to date`	Both sides are the same. (example)	Nothing to do.
`ahead N`	Only your side changed. (example)	Run `git splice push`.
`behind N`	Only the upstream changed. (example)	Run `git splice pull`.
`ahead N, behind M`	Both sides changed since they last matched. (example)	Run `git splice pull`, then `push`. On a conflict, resolve it and `git commit` first.
`!! unrelated history`	Both sides changed and share no history, e.g. the upstream was rebuilt from scratch. (example)	Pick a side. `merge`, `pull` and `push` refuse to guess and print the commands to keep either side, or both.
`unchanged, no upstream branch` or `new, ahead N`	The upstream has no branch with your branch's name. Compared with upstream's default branch, as for a PR: it has every commit of the splice already, or lacks N of them -- also ones from the branch yours was cut from. (unchanged, changed, from `main`, stacked)	Run `git splice push`. It creates the branch only if the default branch lacks commits.

What status compares to tell the states apart: the sync model.

Sync states​

Sync states