jj-sparse(1)

okay so bestie, we're reading jj-sparse(1) today and honestly? she's iconic 💖 this is the manual page for the sparse command in Jujutsu, and she's the one who decides which paths from the working-copy commit actually show up in your working copy. not the commit, not the repo — your working copy. main character energy fr fr ✨

---

🎀 NAME 🎀

jj-sparse — manage which paths from the working-copy commit are present in the working copy 🦋

💫 SYNOPSIS 💫

jj sparse [-R|--repository] [--ignore-working-copy]
[--no-integrate-operation] [--ignore-immutable] [--at-operation]
[--debug] [--color] [--quiet] [--no-pager] [--config] [--config-file]
[-h|--help] <subcommands>

🌸 DESCRIPTION 🌸

okay so real talk: jj sparse is all about managing which paths from the working-copy commit are present in the working copy. that's the vibe. that's the whole job. she's got subcommands for the actual doing of it (scroll down bestie, they're right there 👇) and a whole pile of global options she inherited from the jj family. no cap.

---

💅 OPTIONS 💅

• -h, --help — prints the help. and ngl, if you use the short -h you get the summary version, not the full meal. iykyk.

🌈 GLOBAL OPTIONS 🌈

• -R, --repository <REPOSITORY> — the path to the repository you wanna operate on.

by default, Jujutsu goes hunting for the closest .jj/ directory in an ancestor of the current working directory. she will find it. she always finds it 🔍

• --ignore-working-copy — don't snapshot the working copy, and don't update it.

ok so by default, Jujutsu snapshots the working copy at the beginning of every command (yes, every single one, obsessed), and the working copy also gets updated at the end of the command — but only if the command modified the working-copy commit (@). so if you wanna avoid snapshotting and instead look at a possibly stale working-copy commit, this flag is your girl. super handy in a command prompt, especially if you've got another process out here committing the working copy 🙈

also important, don't skip this part: loading the repository at a specific operation with --at-operation implies --ignore-working-copy. periodt.

• --no-integrate-operation — run the command as usual but don't integrate any operations.

when this option is given, the operations will still be created as usual, but they will not be integrated into the operation log. the working copy will also not be updated, ngl.

the command will print the resulting operation ID. you can pass that to e.g. jj --at-op to inspect the resulting repo state, or you can pass it to jj op restore to restore the repo to that state. you can also pass the ID to jj op integrate to integrate the operation ✨

note that this does not prevent side effects outside the repo. for example, jj git push --no-integrate-operation will still perform the push 💀

• --ignore-immutable — allow rewriting immutable commits.

by default, Jujutsu prevents rewriting commits in the configured set of immutable commits. this option disables that check and lets you rewrite any commit but the root commit. bestie you are so powerful 🫶

this option only affects the check. it does not affect the immutable_heads() revset or the immutable template keyword. don't get it twisted.

• --at-operation <AT_OPERATION> — the operation to load the repo at.

by default, Jujutsu loads the repo at the most recent operation, or at the merge of the divergent operations if any.

you can use --at-op=<operation ID> to see what the repo looked like at an earlier operation. for example, jj --at-op=<operation ID> st will show you what jj st would have shown you when the given operation had just finished. --at-op=@ is pretty much the same as the default, except that divergent operations will never be merged.

use jj op log to find the operation ID you want. any unambiguous prefix of the operation ID is enough 🎯

when loading the repo at an earlier operation, the working copy will be ignored, as if --ignore-working-copy had been specified.

it is possible to run mutating commands when loading the repo at an earlier operation. doing that is equivalent to having run concurrent commands starting at the earlier operation. there's rarely a reason to do that, but it is possible. just so you know. 🤷

• --debug — enable debug logging. she's telling you everything.
• --color <WHEN> — when to colorize output 🌈

possible values:

• always
• never
• debug
• auto

• --quiet — silence non-primary command output.

for example, jj file list will still list files, but it won't tell you if the working copy was snapshotted or if descendants were rebased. warnings and errors will still be printed though — you can't escape those 💜

• --no-pager — disable the pager. no scrolling for you.
• --config <NAME=VALUE> — additional configuration options (can be repeated).

the name should be specified as TOML dotted keys. the value should be specified as a TOML expression. if a string value isn't enclosed by any TOML constructs (such as array notation), quotes can be omitted. so chill of her tbh ✨

• --config-file <PATH> — additional configuration files (can be repeated).

🧚 SUBCOMMANDS 🧚

• jj-sparse-edit(1) — start an editor to update the patterns that are present in the working copy ✏️
• jj-sparse-list(1) — list the patterns that are currently present in the working copy 📋
• jj-sparse-reset(1) — reset the patterns to include all files in the working copy 🔄
• jj-sparse-set(1) — update the patterns that are present in the working copy 🎯

---

and that's the whole page bestie!! this little love letter came out of the sparse manual, filed under jj-sparse(1) — go forth and manage your paths, you absolute icon 👑💖