I have a production server and sometimes I need to copy the files down to my local machine and commit any changes to Bitbucket (I have a very similar issue to this one: https://answers.atlassian.com/questions/38855280 )
When I copy all the files from production to my local machine, it seems that sourcetree thinks all the files have changed when in actuality only a few have changed.
When I click most of the files in the "unstaged files" area it shows no changes:
image2016-6-13 12:45:36.png
How can I get sourcetree to ignore these files (there are hundreds of them in my unstaged files panel).
As we mentioned on the question you linked to, this is almost always the result of a difference in line-endings (Windows CRLF vs Unix LF) in the files.
To help confirm this, you can go to the dropdown above the diff view, and set it to "show whitespace changes". If it then behaves like ALL lines have changed, it is definitely line endings.
Hi, I still get the same as the picture on the original post.... nothing shows up in the diff... (even when "show whitespace" is selected.)
That is strange. If the line endings were the cause it would definitely show up as all lines removed followed by all lines added.
Let's ask GIT what it sees, SourceTree is only a GUI for GIT so it would be GIT telling ST what's changed. Open a console to the working directory and type "git status" for a list of all the modified files, this is where ST gets it's unstaged list.
Next, sample a changed file with "git diff filename.ext" and see what it prints for differences.
git diff --check filename.ext will tell you if the change is purely due to whitespace. No message from get means it's not a whitespace change.
git diff --raw *.py will tell you the status of the change, M for modified, C for copied, etc.
git diff --stat *.py will print a bar graph per file of your insertion/deletions. If insertions == deletions we're dealing with a line-ending problem. If you glob the file names git will automatically pipe more so either spacebar for more or q to quit the list.
git diff --summary *.py will show you the files added/deleted/copied/renamed according to git but not merely internally changed as in line add/delete.
While were at it, type git config --global core-autocrlf and if it returns a blank line it's not set, and that's probably a good setting.
As far as I know, GIT doesn't depend on timestamps to know if a file has changed. It parses the file in the background per it's internal rule set and knows if the file has actually changed and which lines have changed. Somewhere a rule has determined the files have changed. These probes should give a clue as to why.
It looks like you're new here. Sign in or register to get started.
