Display newly tracked files #8317

Paluche · 2025-12-14T23:31:59Z

Tracking file automatically is a neat thing, until you did not want to track a file and it is not ignored yet. This could happen while executing most of the jj command. You can then, easily end-up having unwanted files in your commits, without realizing you have them. I have been working on repositories which does not define the files to ignore properly, or while working on a new feature, I usually think after it has been already tracked to edit the .gitignore or <git-dir>/info/exclude file.

This issue is experienced by many, (see issue #8168, #323 for instance). I think it is best that - at least in the default configuration - we do not do automatic things silently.

We already have a message when auto-rebase is happening, I think it is suited to have one for auto-tracking.

The idea is that the message triggers a potential quick response from the user when one of the newly tracked files is not one they want to be tracked. Helps raise awareness / eyebrows, so newbies get a feedback on what is happening, then get a bit deeper in the feature, what can be the issues and how to work with it properly.

Prior to submitting this PR, I have experienced with different style of display:

Display the whole list of newly tracked files similar to what jj status would do. It felt wrong and very much spam.
Display only the first file and the numbers of other files. Just like jj file untrack does when attempting to untrack non-ignored files. This was ok, but it was too bad to not display all the files when there was only 2 or 3 that could fit on one line.

So the message displays as much files as it can while keeping the message on a single line, based on the terminal width. If there is more, then we say how many more there is.

For instance:

I have another commit, ready to go, which adds a configuration key to disable the message. It felt really necessary when the message was printing all the files, but not so much anymore.

I did not experienced with the watchman feature I do not know if that could have any impact yet.

Tests have been updated, I wanted to be sure of any impact this could have. Current tests seems to already cover all the different cases, I still added some dedicated to this feature.

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

yuja · 2025-12-15T09:24:19Z

lib/src/local_working_copy.rs

        let (file_states_tx, file_states_rx) = channel();
        let (untracked_paths_tx, untracked_paths_rx) = channel();
        let (deleted_files_tx, deleted_files_rx) = channel();
+        let (new_tracked_tx, new_tracked_rx) = channel();


Since "new tracked" paths should be included in file_states_tx/rx, I don't think we need separate channel. Perhaps, the list of newly tracked paths can be returned from FileStatesMap::merge_in().

EDIT: we can also diff tree objects.

I am reworking to include a boolean in the file_states_tx/rx channel indicating when a path is newly tracked.

I don't see the advantage regarding merge_in() or including the boolean in FileState at the moment. Feels a bit overkill to overload FileState for an information which, (as i see it from now) is interesting only for snapshot stats.

I haven't looked yet on how diff tree objects would make it simpler / more effective. I'll enhance my comprehension of the code and try things out.

The code would be more maintainable if we have fewer data sources. Comparing tree objects might be slower than using file states, but the results would be more trusted.

yuja · 2025-12-15T09:29:52Z

cli/src/cli_util.rs

+
+    write!(formatter, "{tracking_str}")?;
+
+    if to_print.is_empty() {


It's probably better to print paths in a similar way to jj status output than attempting to print them in one line. If there are many paths to list, it might be good to omit some of them, though.

Newly tracked paths: bar foo ...

I think it's also good to collapse paths having the same directory prefix. See visit_collapsed_untracked_files() in status.rs

I think it's also good to collapse paths having the same directory prefix. See visit_collapsed_untracked_files() in status.rs
👍

I'll make so the changes on the lib/ side are first correct. Then go back to the printing part. Maybe we will have some more feedback from other users until then.

One other solution would be to have the print style configurable:

all: Print all files:

Newly tracked paths: foo bar foo/foo bar/bar ...

unsigned int: Print at maximum the number of files configured, for instance 2. With the paths collapsed.

Newly tracked paths: foo bar and 1234 other files...

one_line: Currently implemented output, with path collapsed.

Tracking foo, bar and 1234 other files

none: Do not print anything

I don't think we'll need configuration. If tracking new files is common enough to silence this output, we shouldn't add this feature at all.

BTW, some people enable background snapshots or run GUI/shell prompt. They won't see the status message.

Ok no configuration then.

About watchman / tui /gui, I know they won't see the warning, I am initially aiming at the CLI users. I think we should make so the TUI and GUI can do something with that warning. For watchman, I'll eventually start using it and potentially come with another PR.

So after some thoughts, the requirements for the text displayed would be:

Easily parsable, so there is an open door for TUI and GUI to parse it

therefore unique output

avoid being too verbose. Do something similar to the visit_collapsed_untracked_files;

limit the number of lines printed (like 10 lines max), so we do not spam. For any tool that would want to parse the output, there could be a porcelain like option to print all the files, although I don't plan on doing that in this PR.

Do you agree?

Example:

Tracking 1234 new files: foo bar/ (1230 files) ...and 3 other files

Paluche · 2025-12-17T21:15:19Z

Converted to draft until a new version is ready to be reviewed.

Which files the snapshot started auto-tracking is an interesting information to forward to the user. The idea being that doing things automatically is nice, but do not do them secretly.

Tracking file automatically is a neat thing, until you did not want to track the file that just got auto-tracked. This could happen on many jj commands, so you could, easily end-up having unwanted files in your commits, without realizing you have them. We are now printing a message to indicate when jj starts auto-tracking files. With the intent to have a quick response from the user when one of the newly tracked files is not one they want to have tracked. The message to not take more one single line of your terminal, to not spam. It will list the path of as much newly tracked files as possible, and giving the actual number of files it could not print. Hopefully it should trigger the user into running another command (such as `jj status`) to check what is the state of the commit. And take appropriate action to ignore and untrack the unwanted files.

Paluche requested a review from a team as a code owner December 14, 2025 23:32

yuja reviewed Dec 15, 2025

View reviewed changes

Paluche force-pushed the paluche/print-newly-tracked branch from b4c3bf5 to 0f8e01d Compare December 15, 2025 20:45

Paluche marked this pull request as draft December 17, 2025 21:14

Paluche added 2 commits December 17, 2025 22:46

lib: Add list of newly tracked files in SnapshotStats

4bd9252

Which files the snapshot started auto-tracking is an interesting information to forward to the user. The idea being that doing things automatically is nice, but do not do them secretly.

Paluche force-pushed the paluche/print-newly-tracked branch from 0f8e01d to 595078e Compare December 17, 2025 21:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Display newly tracked files #8317

Display newly tracked files #8317

Uh oh!

Paluche commented Dec 14, 2025

Uh oh!

yuja Dec 15, 2025 •

edited

Loading

Uh oh!

Paluche Dec 15, 2025 •

edited

Loading

Uh oh!

yuja Dec 16, 2025

Uh oh!

yuja Dec 15, 2025

Uh oh!

Paluche Dec 15, 2025 •

edited

Loading

Uh oh!

yuja Dec 16, 2025

Uh oh!

Paluche Dec 17, 2025

Uh oh!

Paluche commented Dec 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		write!(formatter, "{tracking_str}")?;

		if to_print.is_empty() {

Display newly tracked files #8317

Are you sure you want to change the base?

Display newly tracked files #8317

Uh oh!

Conversation

Paluche commented Dec 14, 2025

Checklist

Uh oh!

yuja Dec 15, 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!

Paluche Dec 15, 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!

yuja Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

yuja Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

Paluche Dec 15, 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!

yuja Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

Paluche Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Paluche commented Dec 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yuja Dec 15, 2025 •

edited

Loading

Paluche Dec 15, 2025 •

edited

Loading

Paluche Dec 15, 2025 •

edited

Loading