Description

When using core.watchman.register_snapshot_trigger = true, trying to track a file that is larger than the configured auto snapshot maximum becomes seemingly impossible. Both jj debug snapshot and jj file track don't do anything in this case. Once the trigger is disabled, running any jj command fails, with the expected message of a file being too large to track.

Steps to Reproduce the Problem

1. jj git init
2. jj config set --repo snapshot.max-new-file-size 1
3. jj config set --repo core.fsmonitor watchman
4. jj config set --repo core.watchman.register_snapshot_trigger true
5. echo "Hello World" >> too_large
6. jj status

Expected Behavior

Running any command that triggers a snapshot fails or warns about the file in the working copy being too large.

I am not familiar with the fsmonitor implementation, but from what I can gather from the watchman docs, it's possible to pass individual clock times for each queried path. But it seems that would require jj to add some kind of state of which files were not tracked.

• Running jj debug snapshot explicitly would use the fsmonitor information about changed files but warn about the large file. As mentioned above, I'm not sure how feasible it is to do this.
• Running jj file track would completely ignore any fsmonitor, directly attempt to track the file but warn about the large file. This one seems possible today.

Actual Behavior

No error, warning or hint is emitted on any of the commands.

Specifications

• Platform: Linux 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64 GNU/Linux
• Version: jj 0.25.0-6d7f4a7c1ca03e8d5687d7437c1242b5ab39c9a2