Updating the casing of files (at least on macOS with a case insensitive FS) has bizarre behaviour

[Caleb-T-Owens]

I created a file with one casing, committed it, then renamed it. GitButler kept renaming it back and having issues with creating diffs with no additions or subtractions and creating counteracting diffs which created and deleted the file with different casings

[stimw]

how did you rename it?

[Caleb-T-Owens]

I had someFile and wanted it to be called somefile so to do so, I renamed it to somefile2 and then somefile (which you have to do in vim's netrw otherwise won't understand the rename)

[Byron]

Thanks for reporting!

I tried to reproduce the issue with Version 0.11.3 (20240419.070253), but was unable to get into the state you are describing. I did track a lower-case file, changed its case to be capitalized, and in GitButler it would still show up lower-case, just like in Git itself. Changes showed up like expected as well.

Maybe if there has been a bug, it was fixed in the mean time? Otherwise, could you post instructions for how to reproduce it?

[Caleb-T-Owens]

Hi @Byron, thanks for the followup.

Starting with some file called test_helper.rb

1. rename test_helper.rb to ttest_helper.rb
2. commit that rename
3. rename ttest_helper to Test_helper.rb

Gitbutler sees this as a rename back to test_helper.rb

After pushing the remote sees no changes too, so its not just visual

I'm currently on nightly Version 0.5.401 (20240409.030937). I can test a bit later on my other laptop with the latest nightly

[Byron]

Thanks so much for following up!

I did try to follow the instructions, but might have done something different after all, using git mv instead of mv might have been a mistake, starting with bar, commit in GB, git mv bar foobar, commit in GB, then mv foobar Bar.

Thus far, it seems to be alright and doing as expected, at least in my case.

Maybe you can shed some light on the exact commands that you used to perform the rename, even though I would have thought it doesn't make a difference.

This reminds me, rename tracking could also be improved here.

[Caleb-T-Owens]

I used vscode's renaming. I however was renaming a file already in the trunk. If I've created the file in the same branch the rename works fine... this makes me think its related to https://github.com/gitbutlerapp/gitbutler/pull/3510. I'm pretty sure the version of nightly my work laptop is running is before that pr.

[Caleb-T-Owens]

Just went through the faff of updating it on my work laptop (yay for restricted privileges) and it seems like the problem is no more!

I can only presume that the issue was caused because the hunks used to be created by diffing the (integration commit AND uncommitted changes) against origin/master, where as now, its just (uncommited changes) against (origin/master AND integration commit).

Presumably when diffing (integration commit AND uncommitted changes) against origin/master its only seeing the test_helper.rb → Test_helper.rb rename which doesn't get picked up by git. Now that we're diffing (uncommited changes) against (origin/master AND integration commit), its correctly seeing ttest_helper.rb → Test_helper.rb

[Caleb-T-Owens]

Thank you for going back and forth with me on this! Glad that its now resolved, and I'm glad we've got a reasonable explanation