1060 is available now at https://www.sublimemerge.com/dev. I’ve also opened up the Sublime Merge dev builds to all users - it won’t stay like that forever, but it will at least for the next few months.
The changelog for 1060 is fairly small, but the code changes behind it are significant. 1060 has a new implementation of diff_working_dir_to_index, which should now exactly match the git status output for regular files. Previously differences in directory casing between the index and the file system would cause differing output. Given the amount of changes, there’s a good chance of regressions in 1060.
For those following along at home, the previous implementation in Sublime Merge parsed the index into a tree shaped data structure, and then did a straight forward ordered-tree comparison between that and the FS, with some fixup logic to handle the case of files in the FS not matching the case of files in the index. This works well, but it doesn’t easily handle the scenario of folders in the the index being there in different cases: e.g., foo/a and Foo/b, where there’s a single folder named Foo on disk (which is a case-insensitive file system in this example). This situation is solvable, but it gets awkward very quickly, especially when you want to compare the index vs the FS in a case-insensitive manner, but the index vs HEAD in a case-sensitive manner.
1060 handles this by calculating the working directory changes the same way as Git itself: stat each file in the index, and do a second pass over the working directory tree to find any untracked files. From what I can tell, other third party Git implementations work in the same way as Sublime Merge used to pre-1060, which is why libgit2 also appears to calculate the working directory changes incorrectly in these cases.
Please let me know if you see any mismatches vs Git on 1060.