jj-split

Split the given revision into two interactively, putting the second revision on top of it

$ jj split [[-r|--revision]] [revision]

$ jj split [[-r|--revision]] [revision] [fileset]

$ jj split [[-r|--revision]] [revision] [[-d|--destination]] [revset]

$ jj split [[-r|--revision]] [revision] [[-B|--insert-before]] [revset] [[-A|--insert-after]] [revset]

$ jj split [[-r|--revision]] [revision] [[-p|--parallel]]

jj split [OPTIONS] [REVISION]
or
jj split [OPTIONS] --from --to

The REVISION argument defaults to the current commit if not specified.

--from
    Specifies the starting revision for splitting a range of commits when used with --to.

--to
    Specifies the ending revision for splitting a range of commits when used with --from.

-r, --revision
    (Default: @) The commit to split. This is often the most recent commit or a specific commit ID.

-i, --interactive
    Launches an interactive diff editor (e.g., meld, vimdiff) to select which changes (hunks) from the chosen revision should move to the new commit.

-m, --message
    Provides an initial commit message for the first new commit created by the split operation, bypassing the editor.

-s, --tool
    Specifies the diff editor to use for interactive splitting. Overrides the default configured tool.

--at
    When specified, only changes affecting the given path(s) will be considered for splitting.

--edit-original
    Keeps the original commit message but allows editing the new commit's message.

--skip-empty
    Prevents the creation of an empty commit if no changes are selected for one of the split parts.

jj split is a powerful subcommand within the Jujutsu (jj) version control system. It allows users to refactor a single commit into two or more distinct commits, or to split a range of commits. This is particularly useful for cleaning up commit history, separating logical changes, or reordering contributions. When used interactively, it presents a diff of the chosen commit, allowing the user to select which hunks or lines belong to the "original" commit and which should form the "new" commit(s). It effectively rewrites history by creating new commits based on the split content, making it a flexible alternative to operations like git rebase -i for detailed history manipulation.

History Rewriting:
Like many jj commands, jj split rewrites history. New commit IDs are generated, and the original commit becomes obsolete. This can affect collaborators if the changes have already been pushed.
Interactive Nature:
The --interactive flag relies on an external diff editor being properly configured. If no editor is configured or available, the command may fail or behave unexpectedly.
Complexity:
Splitting commits, especially interactively, requires careful attention to ensure changes are correctly allocated to the desired commits.

When jj split -i is used, Jujutsu invokes your configured diff editor (e.g., meld). The editor will display the changes of the chosen commit. You typically mark which hunks or lines should remain in the "original" commit and which should be moved to the "new" commit. The editor's exit status and temporary files determine how the split is performed. After the editor closes, jj creates the new commit(s) and prompts for their messages if not provided via --message.

While jj split achieves similar results to git rebase -i operations (like edit followed by git add -p and git commit), it is often perceived as more straightforward and less error-prone within the Jujutsu ecosystem due to its explicit design for this specific task and integrated interactive tooling.

jj split is an integral part of the Jujutsu (jj) version control system, which was developed by Martin Fowler and others at Google. Jujutsu aims to provide a more intuitive and powerful way to manage version control compared to Git, particularly excelling in local history manipulation. The split command was designed from the ground up to offer a flexible and interactive method for refining commit granularity, addressing common challenges faced by developers in maintaining clean and logical commit histories. Its functionality often replaces more complex Git workflows involving interactive rebasing.

jj(1), jj-squash(1), jj-unsplit(1), jj-rebase(1), git-rebase(1), git-commit(1)