Sourcetree No Changes In This File Have Been Detected

  1. Sourcetree No Changes In This File Have Been Detected Meaning
  2. Sourcetree No Changes In This File Have Been Detected
  3. Sourcetree No Changes In This File Have Been Detected Will
  4. Sourcetree No Changes In This File Have Been Detected For A

In that case you'll see the changed files in Visual Studio but both the Staged file and Unstaged files lists will be empty. In SourceTree you'll notice that there's a little 1 icon next to the word master (still above the '1' arrow) which tells us that there's a commit that we saved locally (on our hard drive) but did not push back to. External diff runs (w/o a reason) each time when I select any of 'Unstaged files' (File Status windows) that are deemed (by the SourceTree) as 'binary' (status: 'No changes in this file have been detected, or it is a binary file'), though these are XML files from Java projects such as:.classpath,.project etc. I didn't test it, but I'm sure if I would have just committed my file with the new Unicode encoding, the next time I made changes to that file it would have shown the changes properly and not detected it as binary, since then it would have been comparing two Unicode encoded files, and not a UTF-8 file to a Unicode file. Fixed duplicate file appearing when checking a file; SourceTree 3.3.7 8 Jan 2020 Changes. Update version of embedded git for security; SourceTree 3.3.6 22 November 2019 Changes. Fixed new branches in the push dialog not setting the remote branch name; Fixed the create patch screen allowing split view; SourceTree 3.3.4 28 October 2019.

  • Status:Needs Triage(View Workflow)
  • Resolution: Unresolved
  • Fix Version/s: None
  • Labels:
  • Environment:

    Affects SourceTree version 2.3.2 but that's not in the list of released versions.

    macOS Sierra 10.12.1

    Used on a git repository containing a meteor 1.4.2 web app, using mongodb.

In my normal working environment I review multi-file changes selecting files or hunks to stage.

But this is nearly impossible with SourceTree, because the diff view keeps refreshing and every time it refreshes the file and line position and scroll position. For me, this is happening every 5 or so seconds. As you can imagine, many a swear word gets uttered during this process.

In my search for an answer, I've seen various bug reports for SourceTree that seem to get shuffled about and closed or not necessarily addressed. Ultimately there are three contributing factors:

  1. Something is changing files
  2. SourceTree refreshes when ANY file change occurs, even ignored files
  3. SourceTree looses position information when a refresh occurs

Sourcetree No Changes In This File Have Been Detected Meaning

Now although item 1 is not SourceTree's fault the consequences given 2 and 3 are really bad. With the greatest respect, there have been so many people who hit these issues that I would strongly suggest 2 and 3 are addressed.

For item 1, I eventually found out what was the problem in my case. I develop apps using meteor (http://meteor.com) and in development mode it runs a mongodb database, which periodically writes diagnostic info (.meteor/local/db/diagnostic.data/metrics.interim to be precise). The whole .meteor folder is in my .gitignore file.

The simple answer of course is that I shut the meteor down while reviewing changes, but that is simply not a realistic option as it would destroy my productivity. I also haven't found a way to disable the mongodb diagnostics.

SourceTree has the ability to disable automatic refreshes, and although this might seem like a great option - as a user it isn't. You only have to miss some changes that shouldn't have been submitted ... etc. and you may end up looking for another job.

One more workable compromise option would be to have an automatic refresh that only kicks in when the SourceTree app gains focus. For most people this would catch manual code changes.

Another suggestion is to have refresh still detect changes, and display a 'Changes detected. Refresh now.' button in the header/toolbar. So that the user is alerted, but not necessarily interrupted.

The best option of course is that file detection skips ignored files/directories (fix issue 2). It clearly should. I've seen a comment in one of the issues suggesting that it might be inefficient, but the consequences are too impactful not to, and the actual refresh has to do that check anyway (albeit inside git).

Maybe the git refresh (git status command at least) can be executed before fully committing to the UI refresh. If the existing view doesn't currently have that file, and the git status doesn't list it - ignore the file change. Even better, use the git check-ignore command which seems perfect for this scenario.

Alternatively, do the refresh in the background, and if the result is identical to the UI's existing state - return without changing anything.

File
Votes:
0Vote for this issue
Watchers:
1Start watching this issue

Last time I wrote about version control using Subversion (and its implementation in Eclipse). I still haven’t given up on it, but since I’m using a private repository, sharing code has been a bit tedious.

I was introduced to git a while ago, but somehow decided to go for Subversion. A few days ago a friend of mine pointed out SourceTree, a git GUI client for Windows and Mac. It’s not all GUI, all you die-hard CLI users are able to use their favorite tool. It hooks well with BitBucket, Stash, GitHub and Kiln. I opted for BitBucket, because it offers free private repositories.

Sourcetree No Changes In This File Have Been Detected

The interface is, to my mind, very intuitive. You have a bookmark sidebar with your favorite projects, main window where most of the magic happens and of course the toolbar, where you can commit, checkout, remove, pull, push, branch, merge (and more) projects. For understanding git, Git Reference site can be helpful.

Once you create a new (local or remote) repository, the program will scan for any possible changes. Once a change has been detected, you will be able to commit them. In git lingo, this means that you will acknowledge these changes and apply them. SourceTree will keep a nice history tab for you, and you can revert to previous versions by simply “checking it out”. Once you’re happy with all the changes and you think your repo should see the light of day, you can Push it to your favorite git site, like BitBucket or GitHub. If you’re collaborating with others, you can always Fetch/Pull changes from the main site and have you repo up to date.

Sourcetree No Changes In This File Have Been Detected

Sourcetree No Changes In This File Have Been Detected Will

If you’re looking for version control, and you see yourself as a prospective (or current) collaborator, do give git and SourceTree a try.

Sourcetree No Changes In This File Have Been Detected For A

SourceTree in action. Left is the bookmark sidebar and the main window is showing the history of my master branch. Click on image to enlarge (the image).