There are times when I need to pull down the latest files from my production server and push changes into GIT. When I pull the files, everything in my local GIT repo gets overwritten - mostly with the exact same files (name, code, location - everything is the same except the timestamp).
Even though 95% of the files are exactly the same as what was there before, Sourcetree seems to consider those file to have changed. In the merge screen I can see the complete code for that file highlighted in red (old) followed by the exact same code highlighted in green (new). There are no differences in the old and new code.
Does this have to happen? It makes these pushes to GIT relatively useless, as there's no way to see what actually has changed. Is there any way to force Sourcetree to just look at the code and not the timestamp (or whatever it uses to determine it's a different file)?
I have only seen this happen when dealing with Linux/OS X line endings vs Windows. Visual Studio wants consistent endings and will offer to convert them if it finds mixed line endings in a file. This leads to whole files looking changed within SourceTree. I've found that keeping to CRLF in Windows and LF in OS X and pushing/pulling via SourceTree on Windows will eventually straighten itself out. Then it doesn't seem to matter whether I push/pull on OS X via SourceTree or Xcode natively.
You might also check your git settings to see if Git is doing something strange with line endings or other whitespace: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#Formatting-and-Whitespace
I've never touched the core.autocrlf on any of my systems. Perhaps this is why a mixed line ending file sneaks in once in a while. I'm writing mixed-platform so I'm constantly alternating between Xcode and Visual Studio.
Query git with git config --global core-autocrlf and if it returns a blank line it's not set.
If it's set, clear it with git config --unset --global core-autocrlf for "default" behavior.
The documentation is not clear and when I am confronted with that situation I am inclined to not mess with default settings.
As I understand it, setting to true on Windows systems causes git to convert LF to CRLF endings automatically when checking out (or presumably, pulling) code. (I have no idea what it does if the file is not text and the cited documentation is deficient in this regard.)
The documentation is also deficient about what the line endings will be in a remote repository when it is set to true on a Windows client and unset on a Linux or Mac client.
Setting it to false causes GIT to ignore all line ending styles, keeping CRLF endings in the repository.
Here's another deficiency: which repository? The term repository applies equally to a local clone and a remote repository on a foreign system. Exactly which repository is it talking about?
Then there's the third option: input.
This keeps line endings as they were input and leaves them untouched on commit.
Here's what git help config has to say:
Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.
Can you please let me know what the solution was and in particular, what the config was in git that solved the issue. I read through the thread and I cannot assimilate what the solution is.
I am stuck with the same issue of sourcetree showing all the files as changed.
Any help, greatly appreciated.
Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot