Opening a new revision with "conflicting" changed files that match prints faulty messages

[NoahTheDuke]

Description

I'm on main, call jj git fetch which says, "Abandoned N commits which are no longer reachable.", then call jj new main@origin so I can start work on a new feature. The resulting message says that there are updates that are "skipped" because of conflicting changes in the working copy, but the hinted commands don't do anything.

$ jj new main@origin
Working copy now at: loxyrzko a5789ca2 (empty) (no description set)
Parent commit      : wsstmzyu 5d4b9306 main | (empty) Merge branch 'nb/push-oovvszxsxsqq' into 'main'
Added 6 files, modified 23 files, removed 0 files
5 of those updates were skipped because there were conflicting changes in the working copy.
Hint: Inspect the changes compared to the intended target with `jj diff --from a5789ca20891`.
Discard the conflicting changes with `jj restore --from a5789ca20891`.

$ jj diff --from a5789ca20891

$ jj restore --from a5789ca20891
Nothing changed.

Steps to Reproduce the Problem

1. I'm not sure what is required to make this happen.

Expected Behavior

Don't print the commands or even say "changes are skipped" if there's nothing to report? Seems like "too much information" if there's nothing for the user to do.

Specifications

• Platform: OSX
• Version: 0.14.0

[martinvonz]

It's talked about the skipped_files here: https://github.com/martinvonz/jj/blob/4cb457eddba95fb67417d49ef3fa75942424bc9c/lib/src/local_working_copy.rs#L1346-L1360

We should probably check if the file on disk matches the target file and not consider them skipped then.

[BatmanAoD]

Why would new skip updating files in the first place? Is this documented somewhere?

[martinvonz]

Why would new skip updating files in the first place? Is this documented somewhere?

In case you missed it, the message above includes this bit:

5 of those updates were skipped because there were conflicting changes in the working copy.

That typically happens if you had files that were ignored in the working copy but are tracked in the commit you're updating to. When we update to the commit where the files are tracked, we skip writing them because you had the ignored files in the working copy already. That way we don't overwrite anything important in the those files, and you can easily inspect the difference between your previously ignored files and the files in the target commit using the hinted command.

[BatmanAoD]

Oh, I saw the message about conflicting changes in the working copy, but I didn't understand why it wouldn't create a new commit to preserve working-copy changes (as usual) and leave them behind. But it makes sense that files that are .gitignored in the working copy but recorded in the commit being checked out wouldn't be appropriate to include in a new commit based on the working copy.