`jj` commands should throw a warning when the fileset does not exist #7693

whereistejas · 2025-10-10T14:07:27Z

Closes #6556.

Checklist

If applicable:

I have updated CHANGELOG.md
I have updated the documentation (README.md, docs/, demos/)
I have updated the config schema (cli/src/config-schema.json)
I have added/updated tests to cover my changes

github-actions

The following commits do not follow our format for subject lines:

a98a670: Use print_unmatched_explicit_paths in cmd_status.
14e7bbd: Update CHANGELOG

Commits should have a subject line following the format <topic>: <description>. Please review the commit guidelines for more information.

All commits are now correctly formatted. Thank you for your contribution!

CHANGELOG.md

cli/src/commands/status.rs

glehmann · 2025-10-22T15:32:42Z

IMO, you should merge the revision that changes the command and the revision that adds the test for each command. It would be easier to review.
And it's a bit strange, given how the revisions are organized, that the number of revisions in the PR is odd :)

whereistejas · 2025-10-22T16:03:31Z

IMO, you should merge the revision that changes the command and the revision that adds the test for each command. It would be easier to review.

I want to make sure that the warning is shown in a consistent manner across all commands. That's why the commands and tests are one after another. I would be happy to split the PR in whatever way is more convenient for the reviewer when ready :)

And it's a bit strange, given how the revisions are organized, that the number of revisions in the PR is odd :)

I didn't have to add tests for all the commands. Some of them already had tests capturing this behaviour, for example, split.

martinvonz · 2025-10-22T16:12:21Z

nit: Could you squash the tests into the commit they're testing? See https://jj-vcs.github.io/jj/latest/contributing/#commit-guidelines

martinvonz

Thanks!

martinvonz · 2025-10-29T16:14:50Z

cli/src/cli_util.rs

+    // If there are no explicit paths to show then return early.
+    if explicit_paths.is_empty() {
+        return Ok(());
+    }


What's the benefit of this check? That should ideally be mentioned in the commit description (if it's not obvious, and it's not obvious to me at least).

Is this just an optimization? But if explicit_paths is empty, then explicit_paths.retain() will be very cheap anyway. So I don't think it's a worthwhile optimization.

Or is it about correctness when explicit_paths is empty and trees is also empty? It makes sense to not print the warning in such cases. Are you going to add callers that may pass an empty list of trees in a later commit? Could you update the commit description to explain that that's the reason if it is?

Actually, if the second thing is what it's about, I would suggest just moving the early return out of the loop. As mentioned above, I don't think it's useful as an optimization anyway. If we move it after the loop, then it will handle the case of an empty list of trees. If you do that, I would suggest actually not making it an early return but instead make the output conditional on the list being non-empty.

It's the latter. Some scenarios when a fileset_expression may evaluate to valid explicit paths but we may not have any trees to compare them against are:

Squashing a commit into itself.

Running jj log -r "none()"

I will add an explanation to the commit message.

cli/src/cli_util.rs

cli/src/commands/status.rs

cli/src/commands/squash.rs

cli/src/commands/split.rs

cli/src/commands/interdiff.rs

cli/src/commands/fix.rs

CHANGELOG.md

cli/src/commands/absorb.rs

cli/src/cli_util.rs

cli/src/commands/split.rs

cli/src/commands/log.rs

martinvonz · 2025-10-31T17:05:39Z

cli/src/commands/log.rs

                let commit = store.get_commit(&key.0)?;
+                let tree = commit.tree()?;
+                // TODO: propagate errors
+                explicit_paths.retain(|&path| tree.path_value(path).unwrap().is_absent());


Hmm, we should also remove paths that are in the parent tree. Otherwise jj log <deleted file> -r <revision where file was deleted> will print the warning. However, it's expensive to calculate the parent tree for merge commits. Perhaps we can remove paths that are in any parent tree instead. That's slightly incorrect because if a file was removed on one of the parent branches of a merge commit then we won't print the warning for the merge commit even though the file wasn't changed or present in the commit. That's probably fine because the point of the warning is to detect typos and such, and if the file did exist at some point, then it's probably not a typo.

It might be good to have tests for these two cases too. To clarify, here's the second case:

$ jj log D (empty) |\ C| (empty) | | | B delete foo |/ A add file foo $ jj log -r D foo # Since foo isn't present or modified in D, we should ideally print a warning but I don't think we can because it's slow

Btw, jj log is also an exception because the user can do either jj log <fileset> or jj log -r 'files(<fileset>)' (or something more complex). We will only show the warning if the fileset was passed as a positional argument, not if it was part of the revset. Not asking for any changes here, just noting this.

I think my suggestion is to leave it as is for now. It should be pretty rare to run into it, and the alternatives have their drawbacks too.

cli/src/commands/interdiff.rs

cli/tests/test_split_command.rs

cli/src/commands/fix.rs

We should not display any warning if `explicit_paths` is empty. Previously, we would by-pass this check if `trees` was empty (which was incorrect behaviour).

We inline `print_unmatched_explicit_paths` when displaying the log as graph for performance reasons.

martinvonz · 2025-11-03T17:03:23Z

cli/src/commands/status.rs

                visit_collapsed_untracked_files(
                    snapshot_stats.untracked_paths.keys(),
-                    tree,
+                    tree.clone(),


nit: Is this change necessary? OTOH, perhaps it's better to move print_unmatched_explicit_paths() later? it seems easier to spot the unmatched paths if we print the after the list of matched paths. (Also see my comment about caching on the jj log commit because I think that's also relevant here.)

martinvonz · 2025-11-03T17:12:00Z

cli/src/commands/log.rs

+                let tree = commit.tree()?;
+                // TODO: propagate errors
+                explicit_paths.retain(|&path| tree.path_value(path).unwrap().is_absent());


nit: Could you move these lines after graph.add_node() block? That should be better for caching because diff_renderer is able to read many trees concurrently (if the backend is slow like at Google) but explicit_paths.retain() doesn't process the paths concurrently. So by moving the serial part after the concurrent part, we can take advantage of the trees read by the concurrent code being in the cache so it's fast to read them serially.

martinvonz · 2025-11-03T17:39:09Z

cli/src/commands/log.rs

                let commit = store.get_commit(&key.0)?;
+                let tree = commit.tree()?;
+                // TODO: propagate errors
+                explicit_paths.retain(|&path| tree.path_value(path).unwrap().is_absent());


I think my suggestion is to leave it as is for now. It should be pretty rare to run into it, and the alternatives have their drawbacks too.

martinvonz · 2025-11-03T17:42:18Z

cli/tests/test_interdiff_command.rs

+    let _ = work_dir.run_jj(["edit", "right"]);
+    work_dir.remove_file("file1");
+    let _ = work_dir.run_jj(["new"]);


nit: replace let _ = by .success()

martinvonz · 2025-11-03T17:45:07Z

cli/src/commands/absorb.rs

+    print_unmatched_explicit_paths(
+        ui,
+        &workspace_command,
+        &fileset_expression,
+        [&source_commit.tree()?],
+    )?;
+


nit: maybe better to print the message after later, around line 131?

martinvonz · 2025-11-03T17:47:41Z

cli/src/commands/fix.rs

        .block_on()
    });
+
+    print_unmatched_explicit_paths(ui, tx.base_workspace_helper(), &fileset_expression, &trees)?;


nit: maybe better to print this a bit later, after any warning from formatters etc., so between lines 190 and 191?

martinvonz · 2025-11-03T17:49:01Z

cli/src/commands/interdiff.rs

+    print_unmatched_explicit_paths(
+        ui,
+        &workspace_command,
+        &fileset_expression,
+        // We check the parent commits to account for deleted files.
+        [
+            &from.parent_tree(repo.as_ref())?,
+            &from.tree()?,
+            &to.parent_tree(repo.as_ref())?,
+            &to.tree()?,
+        ],
+    )?;


nit: maybe better to print this after the diffs?

martinvonz · 2025-11-03T17:56:48Z

Thanks again for working on this. We have a release scheduled for Wednesday. I think it's better to get this merged after the release so we get a chance to test it a bit before it's released. I'm not particularly worried about bugs, but I would like to see that there is no significant performance impact (including at Google) and that we feel that we print the warnings at the right time relative to other output so we don't release it on Wednesday and then change the behavior in some way in the very next release.

whereistejas · 2025-11-04T08:48:34Z

... I would like to see that there is no significant performance impact (including at Google)...

Sounds reasonable.

that we feel that we print the warnings at the right time relative to other output so we don't release it on Wednesday and then change the behavior in some way in the very next release.

I've ensured the warning about unmatched paths is always displayed first, before any other warning. I've kept this ordering consistent across all the commands. Does this address your concern about the warning placement?

martinvonz · 2025-11-04T14:29:45Z

I've ensured the warning about unmatched paths is always displayed first, before any other warning. I've kept this ordering consistent across all the commands. Does this address your concern about the warning placement?

My guess was actually that it's better to display it quite late (see some of the comments I left). I'm not sure which is better, but the fact that we have different intuition for it seems suggest that we should test it on ourselves before releasing it to users :)

whereistejas requested a review from a team as a code owner October 10, 2025 14:07

github-actions bot previously requested changes Oct 10, 2025

View reviewed changes

whereistejas changed the title ~~jj status should throw an error when the fileset does not exist~~ jj status should throw a warning when the fileset does not exist Oct 10, 2025

whereistejas force-pushed the warn-when-fileset-is-missing branch from 14e7bbd to 84fb867 Compare October 10, 2025 14:11

whereistejas force-pushed the warn-when-fileset-is-missing branch from 84fb867 to bea6920 Compare October 10, 2025 14:15

martinvonz reviewed Oct 10, 2025

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

cli/src/commands/status.rs Show resolved Hide resolved

whereistejas force-pushed the warn-when-fileset-is-missing branch 3 times, most recently from fb17003 to d6a7b86 Compare October 13, 2025 16:30

whereistejas changed the title ~~jj status should throw a warning when the fileset does not exist~~ jj commands should throw a warning when the fileset does not exist Oct 13, 2025

whereistejas force-pushed the warn-when-fileset-is-missing branch 3 times, most recently from 0eeeaac to 0c2a608 Compare October 13, 2025 17:30

whereistejas force-pushed the warn-when-fileset-is-missing branch 3 times, most recently from 5e3fd26 to 55ab0d8 Compare October 21, 2025 15:46

whereistejas force-pushed the warn-when-fileset-is-missing branch 4 times, most recently from ccb9689 to 0d8298b Compare October 29, 2025 16:10

martinvonz reviewed Oct 29, 2025

View reviewed changes

whereistejas force-pushed the warn-when-fileset-is-missing branch 5 times, most recently from ddc8109 to 484bd5f Compare October 31, 2025 17:02

whereistejas requested a review from martinvonz October 31, 2025 17:24

martinvonz reviewed Oct 31, 2025

View reviewed changes

whereistejas force-pushed the warn-when-fileset-is-missing branch from 484bd5f to de355eb Compare November 3, 2025 10:20

whereistejas added 10 commits November 3, 2025 10:29

cli: always check if explicit_paths is empty

c6bc6ef

We should not display any warning if `explicit_paths` is empty. Previously, we would by-pass this check if `trees` was empty (which was incorrect behaviour).

cli: jj status warns when fileset doesn't exist

19ee7ee

cli: jj squash warns when fileset doesn't exist

44b7911

cli: jj split warns when fileset doesn't exist

5d5d82c

cli: jj restore warns when fileset doesn't exist

b1faff4

cli: jj resolve warns when fileset doesn't exist

fbe1143

cli: jj log warns when fileset doesn't exist

6152c5c

We inline `print_unmatched_explicit_paths` when displaying the log as graph for performance reasons.

cli: jj interdiff warns when fileset doesn't exist

3bbf776

cli: jj fix warns when fileset doesn't exist

3007977

cli: jj absorb warns when fileset doesn't exist

30fe9ed

whereistejas force-pushed the warn-when-fileset-is-missing branch from de355eb to 30fe9ed Compare November 3, 2025 10:29

martinvonz reviewed Nov 3, 2025

View reviewed changes

jj commands should throw a warning when the fileset does not exist #7693

Are you sure you want to change the base?

jj commands should throw a warning when the fileset does not exist #7693

Uh oh!

Conversation

whereistejas commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

github-actions bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

glehmann commented Oct 22, 2025

Uh oh!

whereistejas commented Oct 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinvonz commented Oct 22, 2025

Uh oh!

martinvonz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

whereistejas Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinvonz commented Nov 3, 2025

Uh oh!

whereistejas commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinvonz commented Nov 4, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

`jj` commands should throw a warning when the fileset does not exist #7693

`jj` commands should throw a warning when the fileset does not exist #7693

whereistejas commented Oct 10, 2025 •

edited

Loading

github-actions bot left a comment •

edited

Loading

whereistejas commented Oct 22, 2025 •

edited

Loading

whereistejas Oct 31, 2025 •

edited

Loading

whereistejas commented Nov 4, 2025 •

edited

Loading