[Bug] Renamed files don't appear in Fork

[tanguylebarzic]

A file has been renamed locally, but it's not displayed on the "Local Changes" view. I can see it just fine when running git status from the command line. Refreshing the repository tab, restarting fork... doesn't help. Note that the number of changes displayed (the X in Local Changes (X)) is correct - in my case it displays 3, same as the number of files changed according to git status, although I can only see 2 files in the "Local Changes" view.

[DanPristupov]

Can you send output of git status --porcelain --untracked-files=all to support@fork.dev?

[DanPristupov]

Something is wrong here. Renames can only be detected in staged changes, so showing 'unstaged' section doesn't help.

[DanPristupov]

Please also send the log file. It is located at ~/Library/Logs/Fork.log

[tanguylebarzic]

Sent by email (Fork.log indeed contains errors about the problematic file)

[DanPristupov]

I think I reproduced the problem.
Did you rename a file and then git add --intent-to-add? Or was it done by some IDE, maybe?

Quick solution is to run git add .

[tanguylebarzic]

I didn't run git add --intent-to-add. I don't think it's linked to an IDE either: if I run mv some-file some-file-copy for any file in this repo, git status will immediately display

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	renamed:    logo.png -> logo-copy.png

and fork will hide the copied file (logo.png in this case), with the log containing:

❌[GetChangedFilesGitCommand.swift:160] > Unhandled unstaged case: ' R logo-copy.png'
❌[GetChangedFilesGitCommand.swift:222] > Invalid format of status string: 'logo.png'

FWIW, I'm only seeing this behavior in this repository - other repositories on my computer work fine (with the deleting file appearing as deleted and the new one as untracked until I git add both). I haven't found anything in the problematic repo's config that could explain the different behaviour though.

[DanPristupov]

1. We will fix this problem in the next update. If it's urgent for you, I can make a hotfix build.

if I run mv some-file some-file-copy for any file in this repo, git status will immediately display

Weird. It looks like a FS listener. Do you use git-fs-monitor--daemon or jj?

[tanguylebarzic]

We will fix this problem in the next update. If it's urgent for you, I can make a hotfix build.

Thanks! Not urgent, the workaround through manual git commands is simple enough.

Weird. It looks like a FS listener. Do you use git-fs-monitor--daemon or jj?

Not using jj, not using git-fs-monitor either. Tried to find the difference with other repos and didn't find anything that would explain the behavior.

[DanPristupov]

Can you check if the problem is fixed in https://cdn.fork.dev/mac/Fork-2.66.5.dmg?

[tanguylebarzic]

It does! The file appears directly as moved in the unstaged area. Actually, I continued to dig and found the culprit thanks to sudo fs_usage -w -f filesystem | grep '/my-repo/.git/index: while I don't use jj, I had installed it a few months ago, and found out that it was configured with the watchman.register-snapshot-trigger: true option. Each time a file was created, jj through watchman was running and modifying the git index with intent-to-add, hence the behavior. Sorry for this, and thanks for the fix!