jj-edit

Set the given revision as the working copy

$ jj edit [revset]

jj edit [OPTIONS] [REVISION]

REVISION
    The target commit to edit. If omitted, it defaults to the working copy's parent commit (the commit your working copy is currently based on). This allows you to edit the immediately preceding commit conveniently.

-r, --revision REVISION
    Explicitly specifies the revision of the commit to edit. This option serves the same purpose as the positional REVISION argument.

-p, --parent
    A convenience option to explicitly indicate that you want to edit the parent of the current working-copy commit. This is often the default behavior if no revision is specified, making it clear you're targeting the immediate ancestor.

-m, --message MESSAGE
    Sets the commit message for the edited commit. Note that this message will be ignored if the commit already has a non-empty description.

The jj edit command is a fundamental subcommand of the Jujutsu (jj) version control system, designed for easily modifying the contents of any existing commit, not just the latest one. Unlike Git's `git commit --amend` which primarily targets the head commit, jj edit allows you to "check out" an arbitrary commit into your working directory. Once the commit's state is loaded, you can make any desired changes to the files, add new files, or remove existing ones. After making your modifications, you would typically use `jj commit` (or implicitly, `jj` will create a new commit if you make changes and then run another `jj` command that expects a clean working directory). This powerful feature enables intuitive history rewriting without complex `rebase -i` operations, as jj treats history as mutable by default, creating new versions of commits instead of directly altering them in place.

Using jj edit modifies history by creating new commit IDs for any changes made, effectively replacing the original commit in the history graph. While Jujutsu's design makes this less disruptive than in Git, care should be taken when collaborating, as published commits should generally be considered immutable. Users should understand Jujutsu's concept of mutable history and how it differs from Git's immutable commits.

The usual workflow involves running `jj edit `, which updates your working directory to the state of that commit. You then make your desired file changes using your favorite editor or IDE. After changes are complete, you can continue with other `jj` commands (like `jj commit`, `jj next`, or `jj prev`), and jj will automatically create a new commit version incorporating your changes and rebase subsequent commits on top of it. If you wish to discard changes, simply run `jj restore --working-copy`.

jj embraces a mutable history model, where commits are not immutable objects. When you edit a commit with jj edit and make changes, a *new* commit is created that incorporates your modifications, and all subsequent commits are automatically rebased onto this new commit. This makes history rewriting much more seamless. If conflicts arise during the rebase process (e.g., if a subsequent commit modified the same lines you just edited), jj will pause and provide tools like `jj resolve` to help you resolve them.

jj (Jujutsu) is a relatively new distributed version control system developed by Google, first publicly released around 2022. It aims to offer a more user-friendly and powerful alternative to Git, especially in handling history rewriting. The jj edit command is a core component of this vision, providing a streamlined way to interactively modify past commits, addressing a common pain point in Git workflows that often required complex `git rebase --interactive` operations.

jj(1), jj-commit(1), jj-squash(1), jj-amend(1), jj-rebase(1)