util snapshot: report resulting state

Make jj util snapshot print a small receipt of the resulting state.
It now prints the current working-copy state and current operation
summary, using existing JJ formatting conventions. When the working-copy
commit changes, it also prints the parent commit summaries, matching
other working-copy update output.

This keeps the command lightweight while making it easier for humans
and tools to see what state it left the repo in.

Author: joshka

CHANGELOG.md

@@ -41,6 +41,9 @@ to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 * Added `jj util backend name` command that prints the backend being used in the
   current repo.
 
+* `jj util snapshot` now reports the resulting working-copy state, and prints
+  the created operation summary if snapshotting created one.
+
 ### Fixed bugs
 
 * `jj bookmark forget` no longer prints `Forgot N local bookmarks.` when no

cli/src/commands/util/snapshot.rs

@@ -12,6 +12,8 @@
 // See the License for the specific language governing permissions and
 // limitations under the License.
 
+use jj_lib::repo::Repo as _;
+
 use crate::cli_util::CommandHelper;
 use crate::command_error::CommandError;
 use crate::ui::Ui;
@@ -21,11 +23,12 @@ use crate::ui::Ui;
 /// Snapshots the working copy and updates the working-copy commit if the
 /// working copy has changed since the last snapshot. Since almost every command
 /// snapshots the working copy, there is very little reason to run this command
-/// as a human; it is mostly meant for scripts.
+/// as a human; it is mostly meant for scripts. It prints the resulting
+/// working-copy state together with the current operation summary.
 ///
-/// If you want to see the ID of the current operation after this command, run
+/// If you want to query the current operation ID directly, run
 /// `jj operation log --limit 1`. However, since that command also snapshots the
-/// working copy, there would be no need to run `jj util snapshot` first.
+/// working copy, there would often be no need to run `jj util snapshot` first.
 #[derive(clap::Args, Clone, Debug)]
 pub struct UtilSnapshotArgs {}
 
@@ -35,14 +38,54 @@ pub async fn cmd_util_snapshot(
     _args: &UtilSnapshotArgs,
 ) -> Result<(), CommandError> {
     let mut workspace_command = command.workspace_helper_no_snapshot(ui).await?;
+    let old_wc_commit_id = workspace_command.get_wc_commit_id().cloned();
 
     // Trigger the snapshot if needed.
-    let was_snapshot_taken = workspace_command.maybe_snapshot(ui).await?;
-    if was_snapshot_taken {
-        writeln!(ui.status(), "Snapshot complete.")?;
+    let did_operation_change = workspace_command.maybe_snapshot(ui).await?;
+    let Some(mut formatter) = ui.status_formatter() else {
+        return Ok(());
+    };
+    let status = if did_operation_change {
+        "Snapshot complete."
     } else {
-        writeln!(ui.status(), "No snapshot needed.")?;
+        "No snapshot needed."
+    };
+
+    writeln!(formatter, "{status}")?;
+
+    if let Some(commit_id) = workspace_command.get_wc_commit_id() {
+        let commit = workspace_command
+            .repo()
+            .store()
+            .get_commit_async(commit_id)
+            .await?;
+        if Some(commit.id()) != old_wc_commit_id.as_ref() {
+            write!(formatter, "Working copy  (@) now at: ")?;
+            workspace_command
+                .commit_summary_template()
+                .format(&commit, formatter.as_mut())?;
+            writeln!(formatter)?;
+            for parent in commit.parents().await? {
+                write!(formatter, "Parent commit (@-)      : ")?;
+                workspace_command
+                    .commit_summary_template()
+                    .format(&parent, formatter.as_mut())?;
+                writeln!(formatter)?;
+            }
+        } else {
+            write!(formatter, "Working copy change (@): ")?;
+            workspace_command
+                .short_change_id_template()
+                .format(&commit, formatter.as_mut())?;
+            writeln!(formatter)?;
+        }
     }
 
+    write!(formatter, "Current operation: ")?;
+    workspace_command
+        .operation_summary_template()
+        .format(workspace_command.repo().operation(), formatter.as_mut())?;
+    writeln!(formatter)?;
+
     Ok(())
 }

cli/tests/cli-reference@.md.snap

@@ -3550,9 +3550,9 @@ Print the CLI help for all subcommands in Markdown
 
 Snapshot the working copy if needed
 
-Snapshots the working copy and updates the working-copy commit if the working copy has changed since the last snapshot. Since almost every command snapshots the working copy, there is very little reason to run this command as a human; it is mostly meant for scripts.
+Snapshots the working copy and updates the working-copy commit if the working copy has changed since the last snapshot. Since almost every command snapshots the working copy, there is very little reason to run this command as a human; it is mostly meant for scripts. It prints the resulting working-copy state together with the current operation summary.
 
-If you want to see the ID of the current operation after this command, run `jj operation log --limit 1`. However, since that command also snapshots the working copy, there would be no need to run `jj util snapshot` first.
+If you want to query the current operation ID directly, run `jj operation log --limit 1`. However, since that command also snapshots the working copy, there would often be no need to run `jj util snapshot` first.
 
 **Usage:** `jj util snapshot`
 

cli/tests/test_util_command.rs

@@ -289,6 +289,9 @@ fn test_util_snapshot() {
     insta::assert_snapshot!(output, @"
     ------- stderr -------
     Snapshot complete.
+    Working copy  (@) now at: qpvuntsm 0f7e5910 (no description set)
+    Parent commit (@-)      : zzzzzzzz 00000000 (empty) (no description set)
+    Current operation: 400986d31c96 (2001-02-03 08:05:08) snapshot working copy
     [EOF]
     ");
 }
@@ -303,6 +306,8 @@ fn test_util_snapshot_nothing_changed() {
     insta::assert_snapshot!(output, @"
     ------- stderr -------
     No snapshot needed.
+    Working copy change (@): qpvuntsm
+    Current operation: 90267f31f904 (2001-02-03 08:05:07) add workspace 'default'
     [EOF]
     ");
 }

docs/FAQ.md

@@ -105,20 +105,20 @@ The wiki lists additional TUIs and GUIs beyond the terminal: [GUI-and-TUI](https
 Colocating a Jujutsu repository allows you to use both Jujutsu and Git in the
 same working copy. The benefits of doing so are:
 
-- You can use Git commands when you're not sure how to do something with
+* You can use Git commands when you're not sure how to do something with
   Jujutsu, Jujutsu hasn't yet implemented a feature (e.g., tagging), or you
   simply prefer Git in some situations.
 
-- Tooling that expects a Git repository still works (IDEs, build tooling, etc.)
+* Tooling that expects a Git repository still works (IDEs, build tooling, etc.)
 
 The [colocation documentation describes the
 drawbacks](git-compatibility.md#colocated-jujutsugit-repos) but the most
 important ones are:
 
-- Interleaving `git` and `jj` commands may create confusing bookmark conflicts
+* Interleaving `git` and `jj` commands may create confusing bookmark conflicts
   or divergent changes.
 
-- If the working copy commit or its parent contain any conflicted files, tools
+* If the working copy commit or its parent contain any conflicted files, tools
   expecting a Git repo may interpret the commit contents or its diff in a wrong
   and confusing way. You should avoid doing mutating operations with Git tools
   and ignore the confusing information such tools present for conflicted commits
@@ -127,7 +127,7 @@ important ones are:
   [\#3979](https://github.com/jj-vcs/jj/issues/3979) for plans to improve
   this situation.
 
-- Jujutsu commands may be a little slower in very large repositories due to
+* Jujutsu commands may be a little slower in very large repositories due to
   importing and exporting changes to Git. Most repositories are not noticeably
   affected by this.
 
@@ -159,7 +159,7 @@ You can also use `jj evolog -r` on revisions that were previously the
 working-copy revisions (or on any other revisions). Use `jj evolog -p` as an
 easy way to see the evolution of the commit's contents.
 
-### Can I prevent Jujutsu from recording my unfinished work? I'm not ready to commit it.
+### Can I prevent Jujutsu from recording my unfinished work? I'm not ready to commit it
 
 Jujutsu automatically records new files in the current working-copy commit and
 doesn't provide a way to prevent that.
@@ -282,9 +282,9 @@ $ jj log
 
 Now you're ready to work:
 
-- Your work in progress _xxxxxxxx_ is the first parent of the merge commit.
-- The private commit _wwwwwwww_ is the second parent of the merge commit.
-- The working copy (_vvvvvvvv_) contains changes from both.
+* Your work in progress _xxxxxxxx_ is the first parent of the merge commit.
+* The private commit _wwwwwwww_ is the second parent of the merge commit.
+* The working copy (_vvvvvvvv_) contains changes from both.
 
 As you work, squash your changes using `jj squash --into xxxxxxxx`.
 
@@ -459,13 +459,13 @@ Working on feature B
 #### Step 3: Move any bookmarks to the original revision
 
 ```console
-$ jj bookmark move --from 31a347e0 --to b8004ea8
+jj bookmark move --from 31a347e0 --to b8004ea8
 ```
 
 #### Step 4: Abandon the unwanted revision
 
 ```console
-$ jj abandon 31a347e0
+jj abandon 31a347e0
 ```
 
 Now, we have achieved the exact state we desired:
@@ -571,10 +571,10 @@ commits associated with it.
 ### I'm experiencing `jj` command issues in a Vite/Vitest project, how do I fix this?
 
 When using Vite or Vitest in a Jujutsu repository, you may experience:
-- Very slow vitest startup times
-- Timeout errors in `jj` terminal commands
-- Errors with 3rd party visual tools like `jjk` or `visual-jj`
-- Corrupted `working_copy.lock` files
+* Very slow vitest startup times
+* Timeout errors in `jj` terminal commands
+* Errors with 3rd party visual tools like `jjk` or `visual-jj`
+* Corrupted `working_copy.lock` files
 
 This happens because Vite watches the `.jj` directory where Jujutsu stores its internal state.
 This creates unnecessary overhead as Vite processes Jujutsu's frequent internal file changes,
@@ -608,13 +608,14 @@ whatever reason, such as for scripting, prompt info, or periodic snapshots in
 parallel with something like a
 [`watch` command](#can-i-monitor-how-jj-log-evolves), you can run
 `jj util snapshot`. By default this command will print whether a snapshot was
-taken, which you can silence with the global `--quiet` flag. This command is
+taken together with the resulting working-copy state and the current operation
+summary. You can silence this with the global `--quiet` flag. This command is
 likely most useful for scripting rather than for running on the command line by
 a human.
 
-If you want to see the ID of the current operation after this command, it would
-be simpler to run `jj operation log --limit 1` directly, since that command also
-takes a snapshot if needed.
+If you want to query the current operation ID directly, it may be simpler to
+run `jj operation log --limit 1`, since that command already takes a snapshot if
+needed.
 
 ### I want to write a tool which integrates with Jujutsu. Should I use the library or parse the CLI?
 
@@ -642,12 +643,9 @@ revsets. This seemed unlikely to be accepted by the Git project.
 
 [change]: glossary.md#change
 [change ID]: glossary.md#change-id
-[colocated]: glossary.md#colocated-workspaces
 [commit ID]: glossary.md#commit-id
-[commits]: glossary.md#commit
 [config]: config.md
 
-[gerrit-integration]: https://gist.github.com/thoughtpolice/8f2fd36ae17cd11b8e7bd93a70e31ad6
 [gitignore]: https://git-scm.com/docs/gitignore
 
 [operator]: revsets.md#operators