Use this guide to manage Carbon repository changes with Jujutsu (jj), a Git-compatible version control system. It covers status, diffs, commits, remote syncing, and change stacks, including how to identify a stack's base and handle history safely.
Instructions for using Jujutsu (jj) for version control in the Carbon repository.
Run score Not tested
See how to installThis guide covers everyday version control in the Carbon repository with Jujutsu (jj). It explains how to fetch from a remote, start a change on trunk, inspect repository status, history, and diffs, and commit changes. For a stack of changes intended for a pull request, it describes how to use bookmarks to find the stack’s base and limit commands to the relevant range. It also covers folding work into an existing change and writing change descriptions.
Use this guide when your Carbon checkout uses Jujutsu and you need help with routine version control tasks. It can help you determine which bookmark a change stack is based on, work with a stack that includes changes under review, and check the impact before rewriting history.
Use jj when the repository root contains a .jj directory; otherwise, do not use it. Add --no-pager to jj commands. Never rewrite history for a change already submitted as a pull request. For other existing changes, present the exact squash, rebase, abandon, or describe command and wait for confirmation before running it.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 26, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Jujutsu is a Git-compatible version control system that may be used in Carbon checkouts.
[!IMPORTANT] You can detect if Jujutsu is in use by checking for a
.jjdirectory in the repository root. If present, you must usejjand must not usegit. If absent, you must not usejj.
Always use the --no-pager flag when invoking jj to prevent the command from
blocking or waiting for terminal paging.
jj --no-pager git fetchjj --no-pager new trunkjj --no-pager statusjj --no-pager logjj --no-pager diffjj --no-pager commit
jj commit over the combination of jj describe
and jj new.jj --no-pager abandonjj --no-pager rebase -o trunkA change is often built as a stack of commits sent up as a single pull request.
The stack is not necessarily based on trunk; it may be based on another change
that is itself still in flight.
[!WARNING] Never rewrite the history of a change that has been submitted as a pull request. Reviewers track a PR by its commits, and squashing, reordering, or abandoning them discards review that is already in progress. This cannot be undone from their side.
Before rewriting history in any other case, propose the exact command and wait for confirmation. This applies to
squash,rebase,abandon, anddescribeon an existing change.
Bookmarks delimit the stack. List the bookmarks that are ancestors of the working copy, nearest first:
jj --no-pager log -r '::@ & bookmarks()'
Reading the result takes care, because two situations produce similar output:
trunk is only ever a base. Finding trunk nearest means new work is being
built on top of it, never that trunk itself is being worked on.
The graph does not distinguish the two cases: an unbookmarked or empty commit above a bookmark may be the next commit of that change or the start of a new one. Ask which it is when it is not clear, and ask before choosing where a fix should land rather than after. Guessing wrong means squashing into a change that may already be under review.
Once the base is known, use it to scope commands to the current stack:
jj --no-pager log -r '<base-bookmark>..@'
jj --no-pager squash --into <change-id> [path]. Follow-up fixes and
formatter reflows belong in the change that introduced the code, not in a
trailing "fixes" commit, unless that change has already been submitted.
Naming a path squashes only that part of the working copy, leaving unrelated
work in place.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use this skill to read GitHub issue details and comments from the command line with `gh`. It covers issues referenced by number or URL, including issues in other repositories, and keeps access read-only so issue state is not changed.
Use this skill to guide an AI assistant working in the Carbon repository on viewing, searching, and editing files with specialized environment tools. It also sets rules for temporary files and when custom programs may be used.
Follow the Carbon project's Bazel workflow through Bazelisk, a version-managing launcher. Learn commands for building targets, running tests and binaries, enabling AddressSanitizer, and refreshing cached state after system dependency changes.
Use this skill to implement builtin functions in the Carbon compiler, from registering a function name and checking its signature to evaluating constant calls and generating LLVM IR for runtime calls. It also covers prelude bindings and focused tests.
Apply Carbon toolchain conventions for formatting Bazel, C++, Carbon, Markdown, and Python files. The skill also covers clear comments and documentation, accurate names, design choices, and concise commit descriptions.
Use this skill to add or revise diagnostics in the Carbon toolchain. It explains how to register message kinds, format typed arguments, attach source labels and context, and verify that diagnostics follow the project’s wording and test coverage rules.