Skip to content

reparent

Change a branch's parent — the feature it stacks onto — without touching any commits.

git city reparent <new-parent> [--branch <b>] [--dry-run]

reparent edits lineage metadata only. It rewrites the recorded parent (git-city.branch.<name>.parent in Git config) so the branch now claims a different feature — or the trunk — as its base. The commits do not move at this point. The next sync is what physically rebases the branch onto its new parent.

This split is deliberate: changing where a branch belongs in the stack is a fast, safe, metadata-only edit, while moving the actual commits is a rebase you opt into when you are ready.

Arguments and options

Argument / option Description
<new-parent> The branch the target should now stack onto. Required.
--branch <b> The branch to reparent. Defaults to the current branch.
--dry-run Print the exact ordered git commands and execute nothing.

No clean tree required

reparent does not move commits or touch your working tree, so — unlike commit-moving commands — it runs even when the tree is dirty. The same is true of switch. You do not need to commit or stash first.

What it rejects

reparent validates the request against the current branch tree and refuses anything that would produce an invalid hierarchy:

Rejected Why
Cycles A branch cannot end up as its own ancestor.
Unknown parents <new-parent> must be a branch git-city knows.
Self-parenting A branch cannot be its own parent.
Trunks The trunk (and perennials) have no parent and cannot be reparented.

Rejections print as a clean git-city: <message> on stderr with exit code 1 — never a traceback.

Example

Suppose ui was started off api, but it turns out ui does not actually depend on api — it should sit directly on main.

main  (trunk)
└─ api  ↑3 ↓0
   └─ ● ui  ↑2 ↓0

Re-home ui onto the trunk:

git city reparent main --branch ui

The recorded parent flips immediately, and tree reflects the new lineage:

main  (trunk)
├─ api  ↑3 ↓0
└─ ● ui  ↑2 ↓0

At this moment only the metadata has changed — ui's commits still sit on top of api's. Bring them across with a sync:

git city sync ui

Sync rebases ui onto main, dropping the api commits it no longer inherits, and force-pushes with --force-with-lease if ui is tracked.

Preview the move first

Pair reparent with sync --dry-run to see exactly which commands the eventual rebase will run before you commit to it:

git city reparent main --branch ui
git city sync ui --dry-run

reparent vs. insert

Both edit lineage, but they answer different questions:

  • reparent moves an existing branch onto a different existing parent.
  • insert slots a brand-new branch between a branch and its current parent.

If you want to interpose a new layer in a stack rather than re-home a branch, reach for insert.

→ insert

See also

  • sync — the command that actually moves the commits after a reparent.
  • The mental model — parents, the branch tree, and stacks.
  • insert — add a new branch between a branch and its parent.