Stuck after refactoring filename in Xcode

[ichoosetoaccept]

I refactored a file by capitalizing the first letter in its filename to a capital letter (in Xcode 15.4 (15F31d)).

Since then, Gitbutler is going crazy.

No matter how many times I commit this change the file never disappears from the "Changed files" list. it doesn't seem to be able to commit the change properly.

My screenshot shows the last three commits had "0 changed files" but Gitbutler disagrees with itself in the Changed files list at the top.

[ichoosetoaccept]

Update: I was able to fix the issue, but not with any built-in Gitbutler mechanism. The key was to remove both files from Git's tracking and then add back only the correctly named file. After some more commands I don't exactly remember, I first got this from Gitbutler: Backend error: git command exited with non-zero exit code 1: ["push", "--quiet", "origin", "854ca35577e11419e88b69a32ed4dc87cd005fee:refs/heads/Virtual-branch"] STDOUT: STDERR: To github.com:myusername/voodoodo.git ! [rejected] 854ca35577e11419e88b69a32ed4dc87cd005fee -> Virtual-branch (non-fast-forward) error: failed to push some refs to 'github.com:myusername/voodoodo.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and integrate the remote changes hint: (e.g. 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Somme commands later Gitbutler was showing "HEAD is dirty", which I was also able to resolve.

Just adding this to provide more detail.

[Byron]

Thanks so much for reporting!

I think there must be quite a few shortcomings related to handling case-insensitive filesystems correctly, and this is one of them.

Here is how I could reproduce it (on MacOS on GitButler v0.12.13).

• create a file file and commit it
• change the case of file (i.e. mv file tmp; mv tmp FILE)
• The change is detected as removal and addition, so add file and FILE to a commit in GB
• file should still be listed as modified now, which is strange as all changes should have been comitted.
• commit file - it is now listed in a commit with zero changed files

Notably, git will still show the file as newly added and the worktree will be dirty.