Weird behavior with filenames case

[call0fcode]

In the changes area I see files that I've not deleted nor changed.

In fact, I've never touch them .. they just where there when I added the repo from a local folder.

The interesting part is that they have the same names but different cases. I'm on a Mac and as far as I know, OSX ignores the case and treats files with same name but different case as if they were the same file.

I also don't see the files on VSCode but I do see them in the repo's main branch in Azure 🫠

What can I do to get rid of them and have the changes area clean again?

Many thanks in advance for the help 🫡

[Byron]

Thanks for reporting!

May I ask which version of GitButler you are using?

I think the problem here is that the repository has two files which 'fold' into a single file name on case-insensitive files systems. In this case, git status would show the file as changed as it's always 'wrong' for one of these entries.

Coincidentally I am currently rewriting this part so in future it would start out no better than Git, and show a single change instead of two just like git status would.

Edit: Even in a repository with two overlapping files (new and NEW) with different content for each I wasn't able to have both of them listed 'most' of the time. Sometimes two versions of the file showed up in different lanes, and GitButler would then keep them 'deleted' no matter what I would do.

[call0fcode]

Hi @Byron 😃

Thanks for reviewing and reproduce it!

I'm using the version 0.14.4.

Thanks for the explanation, I've faced this behavior several times on Mac when my team just decides to change the case of a directory or a file.

It's a bit annoying to see the "changes" on the lanes cause they make "noise" and that's why I wanted to report it, but I can live with it.

I just tell my colleagues to remove the files not being used in the project to see what happens. I think they should disappear from the lanes this way.

And yep, it would be nice if GitButler could handle this situation somehow in the future 😉

[stevelw]

I think I have a related bug.

I have a file called [ArtefactId].tsx which I tried to rename to [artefactId].tsx, and GitButler has got really weird about it.

• Renaming the file with GitButler open adds a delete file to the index and instantly removes the file
• Trying git restore instantly adds deleting both files to the index with GitButler open

[Byron]

Thanks for sharing @stevelw. I'd be interested in learning what happens if you type v3 while outside of an editable element. This will switch to the next release which uses gitoxide to perform the git status operation, so I'd expect the behaviour to be much more sane.