Source control
From Git commands to Vex workflows
Use this table when moving from a branch-and-staging workflow to Vex-native source control. Vex keeps JJ changes and bookmarks separate, then publishes explicit targets.
The essential shift
No staging area. Edit files directly; Vex snapshots them into the current change automatically.
Changes stack naturally. Use vex new, vex rebase, and vex squash instead of manufacturing branches for every step.
Publishing is explicit. Point a bookmark at the intended change, then run vex push <target> to advance the hosted ref.
Everyday work
Start with vex clone <org>/<repo>. In a Vex-native checkout, use these commands for working-copy and change-graph operations.
| Task | Git | Vex | What Changes |
|---|---|---|---|
| Clone a Vex repository | git clone <url> | vex clone <org>/<repo> | Use the organization and repository slug, for example vex clone acme/home. |
| Check the working copy | git status | vex status | Vex snapshots the working copy automatically; there is no staging area to inspect. |
| Add or remove files | git add <path> / git rm <path> | Edit or remove the file directly | The current JJ change records file changes automatically. Do not run git add in a Vex-native checkout. |
| See a diff | git diff HEAD | vex diff | Use vex diff -r <revision> for a particular change or vex diff --from <revision> to compare it with the current change. |
| Commit current work | git commit -m "message" | vex commit -m "message" | This finalizes the current change and starts a fresh empty change above it. |
| Start related work from a target | git switch -c topic <target> | vex new <target> -m "message" | Vex creates a new change on the target. Stacks are a chain of changes, not a separate branch per commit. |
| Inspect history | git log --oneline --graph | vex log -r ::@ | Use vex log -r master..@ to inspect work above a target. |
| Create or inspect a branch | git branch / git branch topic <revision> | vex bookmark list / vex bookmark create topic -r <revision> | A Vex bookmark is the named ref that gets published. The default target is commonly master. |
| Move work onto a newer target | git rebase <target> | vex rebase -s <change> -o <target> | Use -s to replay a change and its descendants together. Vex keeps conflict state in the graph instead of interrupting the operation. |
| Amend the previous change | git commit --amend | vex squash | vex squash moves the current change into its parent. Use vex describe to edit a change description. |
| Temporarily set aside work | git stash | vex new @- | The old working-copy change remains a sibling. Return to it with vex edit <change>. |
| Discard or recover work | git restore <paths> / git reset --hard | vex restore <paths> / vex abandon / vex undo | Restore discards selected file changes, abandon removes a change, and undo recovers the last repository operation. |
Publish and review
A bookmark names the target you publish. For a direct-push workflow, finalize the change, point the target at it, and push. For reviewable work, submit and queue the stack instead.
vex commit -m "Describe the completed change"
vex bookmark set master -r @-
vex push master| Task | Git | Vex | What Changes |
|---|---|---|---|
| Publish one Vex target | git push origin <branch> | vex bookmark set <target> -r @-
vex push <target> | vex push advances that target’s hosted Git-compatible ref. In the standard flow, @- is the commit just finalized by vex commit. |
| Review a stack | git push; open a pull request | vex submit -r '<target>..@' --target <target> | Submitting an unchanged stack is idempotent. Each stable Vex change becomes a reviewable diff. |
| Refresh a review stack after target movement | git fetch; git rebase origin/<target> | vex sync --target <target> | Sync fetches the target, removes a landed prefix, restacks remaining work, and updates the hosted review. |
| Queue a ready stack to merge | Merge a pull request | vex stack merge --target <target> | The target queue validates and lands eligible work in order. Use vex stack log to inspect stack and check state first. |
When to use Vex Git compatibility
Use vex git when you are deliberately operating on a Git remote or consuming a Git-compatible path. For example, vex git clone <url> <directory> follows JJ's Git interoperability workflow.
Use vex clone, vex status, vex commit, and vex push inside a Vex-native checkout. A native vex push advances a named Vex target; it is not a generic replacement for every Git remote operation.
Existing Git and GitHub repositories can also be imported and synchronized through Vex when they must remain connected to an external provider.