Version 4.2.4 - still happening.
This issue can lead to substantial time waste for those who run into it (many hours in my case).
Also, it undermines trust in the tool in general, as now you can never be sure what else SourceTree has arbitrarily decided not to show.

Fixed in latest 4.1.3 version

Still happening on source tree 4.0 (229), there's an option to show typechanges or what?

Still happening in SourceTree 3.0.1. Can really mess up your repo when updating cocoapods. For example: upgrading across version 2.4 of Google Maps SDK changes the module symlinks to actual files. Sourcetree doesn't see those changes at all!

4 years and still happening. WTF

Just spent another 2 hours because of this issue. See screenshot: 

Hope once you will fix this issue.
UPD: I can reproduce it on Version 2.6 (123)

@Brian: It could be related, but I am not sure it is the same problem. Problem here exists even before Commit, namely that the changeset is not shown completely (type changes are changes too, but not displayed in SourceTree GUI). Problem there is that something doesn't work after checkout.

Unless I'm misreading this it sounds like what's being tracked here currently: SRCTREE-3055

dmitrii.aitov1299054105 Agree it's annoying, but in the mean time (did anyone from Atlassian say they are working on it?) – maybe add a pre-commit hook that will prevent committing anything while there are uncommitted typechanges. Or, a post-commit hook that will warn you there are such changes, so you can fix before pushing.

Still happening on 2.2 (46). If you are working with CocoaPods you will be so annoyed with this issue. Half of my commits have something like this in message "Forgot to add typechange changes". SourceTree is great and i want to continue using it but please fix this issue.

Please fix this issue. Just caused a lot problem when crashlytics was updated

Still hit this issue cause the changes of symbolic link file. Those type changed files won't show in sourceTree.

Just been hit by this issue and spent ages trying to workout why rebase wouldn't work due to "unstaged changes" when there were no unstaged files listed in sourcetree. After staging from the terminal the typechange files did show up in sourcetree as staged changes

As a part of upgrading to latest versions of Fabric and Crashlytics frameworks for an iOS app, the Fabric and Crashlytics symlinks (shortcuts) were replaced with the actual binary files. Sourcetree didn't detect these changes and so the actual binary files never got committed and as a result, the Xcode project would build successfully only on the machine where the upgrade took place and the binary files exist but everyone else got a linker error because the actual binary file never got committed to github repo.
I had to resort to command line to fix the issue.

Screenshot attached.

Attaching a screenshot to demonstrate the typechange detection issue while upgrading to latest version of Crashlytics and Fabrics SDKs in an iOS Xcode project

Just stumbled on the same bug. It's quite nasty in our case, because it happened on stuff that was automatically updated by Crashlytics/Fabric.

I suspect that every iOS project using Crashlytics will encounter the issue when migrating to Fabric. It actually broke our build, so we lost a few hours to this bug

This should really be fixed. It's a major, basic issue, and is still present over a year later, as of Mac version v2.0.5.2. I'm seeing the same behavior as Matthias... simply changing a committed symlink to a non-symlink is invisible to SourceTree. Of course, the contents of the file can be completely different, and still not be visible as a change in SourceTree. In my case, an SDK plug-in that we use automatically made such a change as part of an update process, caused a problem for our build, and the change was hidden. I spent hours trying to figure out why things were broken when our repo was clean according to SourceTree. Later, I almost committed these invisible and broken changes along with some other changes, since I did a "git add ." on the command line, and then reviewed the changes in SourceTree, trusting it to show the same thing as "git status". I can't trust SourceTree until this is fixed.

Still an issue in 2.0.3, FWIW.

Had this issue today - our situation was exactly as Matthias described. Running SourceTree v2.0.3. We ending up adding and committing the typechange files from CLI

No, the issue itself can be observed without git-annex. I just mentioned git-annex to give a real use-case where this problems happens. For fixing it no knowledge of git-annex is needed.

The issue is just: Command-line git shows typechange diffs (letter "T"), but SourceTree shows these files as unchanged.

To reproduce, commit a symlink file. Then replace this file by a non-symlink file (with same name). SourceTree should show a change like "git status".

Thanks!

Hey guys,

I'd need to investigate this one further. Symlink's aren't always a file stored in that location on disk (depends on if they're a fast or slow symlink). Also, I'd need to see how git-annex is actually able to tell there's changes in the symlink'd files.

With git-annex, git is instead "a stupid filename and metadata" tracker. The contents of annexed files are not stored in git, only the names of the files and some other metadata remain there.

And...

The contents of the files are kept by git-annex in a distributed key/value store consisting of every clone of a given git repository. That's a fancy way to say that git-annex stores the actual file content somewhere under .git/annex/

SourceTree doesn't have any interaction with anything under .git apart from calls through Git itself (and some other really specific stuff). This probably means that git-annex is hooking into Git itself, and if that's the case

According to the annex docs, though, to get a 'git status' you have to use 'git annex status' which would use the extension to then determine the status of files based on the symbolic links.

status [path ...]

Similar to git status --short, displays the status of the files in the working tree. Shows files that are not checked into git, files that have been deleted, and files that have been modified. Particularly useful in direct mode.

So, based on all this, I'm assuming you want SourceTree to detect if there's an annex sub-folder in the .git directory and make annex extension calls based on that?

Cheers

Also had this same problem today, changed a symlink to a real file and no changes was shown on SourceTree, had to fix by command line.

Version 1.9.3.1

This bug is also present in 1.90

The issue also prevents resetting the work tree to a clean state if "git status" lists typechanges, because SourceTree thinks it is already clean.