SourceTree App says uncommitted changes even for newly-cloned repository - what could be wrong?

Question

A remote git repository is just cloned to a local box using Atlassian SourceTree. Even no files have really been modified in the work tree, Atlassian lists a bunch of files right away under "Uncommitted changes". Each file shows same line count both as removed and added, and this count equals to the total count of lines in the file. This would somehow give a hint that we're hitting some kind of line ending problem.

However, the repository's .gitattribute contains

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

that per GitHub article Dealing with Line Endings should make explicitly core.autocrlf true for the repository. However also ~/.gitconfig contains autocrlf = true.

If the modified files are tried to be "reverted" back to previous commit, there is no effect. Same files are still seen as uncommitted.

The repository has been cloned into multiple locations and ensured that no files have been in the same path, to make sure that SourceTree or git do not remember old files.

The repository is collaborated with Windows, Linux and OSX boxes. This problem appears only in OSX.

What could still be wrong in the SourceTree/repository/git setup?

---

Update #1, 20. Apr 2013

As there is still something wrong, here are partial outputs of git config --list.

From SourceTree console (OSX)

core.excludesfile=/Users/User/.gitignore_global
core.autocrlf=input
difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"
difftool.sourcetree.path=
mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED"
mergetool.sourcetree.trustexitcode=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.autocrlf=true

Here is corresponding output from Windows side:

core.symlinks=false
core.autocrlf=false
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
http.proxy=
core.autocrlf=true
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.eol=native
core.autocrlf=true

And full .gitattributes for the repository in question

# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto

*.php    text
*.twig   text
*.js     text
*.html   text diff=html
*.css    text
*.xml    text
*.txt    text
*.sh     text eol=lf
console  text

*.png    binary
*.jpg    binary
*.gif    binary
*.ico    binary
*.xslx   binary

Bronco

Regarding autocrlf, you say it's set in ~/.gitconfig, but if it's set in your repository's .gitconfig then it'll override the global config. Have you tried setting autocrlf in your repository .gitconfig to true? – Blakeney

@KieranSenior to be honest, I have not. Now reviewing the output and I can see that in both, Mac and Win, there are two lines of autocrlf - and they differ completely from each other even in same box. So, I think we have to try setting all possible autocrlf's to true. But - I think that .gitattribute should also do something here, shouldn't it? There we have * text=auto in the first row... – Bronco

Yeah, so text=auto would do as is stated in the git docs based on my answer below. It should auto-convert your line endings. If, for example, you removed that option and checked out your repository again then you shouldn't have a load of files listed as modified. – Blakeney

Just to add, I'm hoping we're not straying from the original problem, as you said in your comment autocrlf vars should be set to true. The best place to set it is in your local repo instance. If text is set to auto then as noted in the docs on checkin it'll normalize the line endings automatically. My below answer does cover these two situations so I think it's relevant, however it might not be addressing your problem exactly. Let me edit it a bit. – Blakeney

It seems that there are differences between using the SourceTree embedded and system Git also - switching to the system version does not report on changed files due to line ending issues. Note: in my case => embedded version = 1.8.0 , system version = 1.79. – Aenneea

Answer 1

I'm one of the SourceTree developers (I develop the Mac version of the product, actually), so hopefully I can be of some help.

Windows machines convert CRLF to LF when committing and LF to CRLF when checking out. autocrlf makes sure everything is LF within the repository. The option text = auto is the one we're interested in though as it says in the docs:

When text is set to "auto", the path is marked for automatic end-of-line normalization. If git decides that the content is text, its line endings are normalized to LF on checkin.

So you see on checkin it will say "Hey, I need to normalise these line-endings because they're not in LF format, but in CRLF." and thus modifies your working copy to do the work it's expected to do. Usually on Mac/Linux you wouldn't need to normalise because everything is in LF, but Git will do a check because you might've checked out from a repository that was previously developed on Windows, or perhaps in an editor that was using CRLF instead of LF.

So in short, you'd probably want to re-commit all of those files as they should be in LF format, but also make sure autocrlf = true (edit, always to true!) in your Windows repository as it says in the docs:

If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the config variable "core.autocrlf" without changing any attributes.

Although imagine that previous quote was when setting autocrlf for a specific repository as well as globally.

Hopefully that's of some help, if not, feel free to ask more questions!

---

Here's a good SO post re: line endings: Why should I use core.autocrlf=true in Git?

---

EDIT

Based on the above answer we need to make sure of a few things here.

• That you've set the relevant git options in your .git/config
• If you want to keep CRLF line endings then set autocrlf=true
• If, when checking out your repository, you don't want your line endings to be automatically converted (causing all your files to be in the "modified" state immediately) then set the text option to unset. Add this option if a global git config has it set to a value you don't want.
• If you're working on both Windows and Mac for a project then it's best you have text=auto and make sure LF is used across the board. This is why problems like this creep in; because your git config's differ or because the initial project/git setup on Windows assumes CRLF when your Mac assumes LF.

Blakeney

Hi! Thanks for your response. Unfortunately we haven't been able to solve the issue even by going through the links to documentation. I updated my question with git config --list output and .gitattributes if you or anyone else could find out what's wrong... – Bronco

Thanks Ville, I'll take another look into it based on the updated information. – Blakeney

The issue for me was .gitattributes had * text=auto. Removing that fixed the issue. If you choose to delete the file entirely, be sure to stage the changes, otherwise you won't see if it fixed the issue. – Crony

I thinks there is some bug in sourcetree in 1.3.3.0. Because core.autocrfl has higher priority then .gitattributes – Ragen

@Ragen SourceTree is just calling Git, so Git in this case should be determining the priority. The more local a Git configuration is, the higher the precedence it has in the chain, so it's likely setting core.autocrlf in the local .git/config may overtake .gitattributes dependent on where that's located. – Blakeney

@KieranSenior So look at that #22833683 – Ragen

Answer 2

I still don't understand it 100%, but for us the issue was the * text=auto in the .gitattribute file in the repository. I checked, and we for sure have core.autocrlf=true set in every place it can be set for my user on a Windows PC. I knew it wasn't a SourceTree issue either, as TortoiseGit and just Windows Git (msysgit) all had the same "issue" for this repository. Really odd behavior - I would clone the repo one time and immediately see 11 "different" files, then I would delete and start over and the next clone would have 14 "different" files.

Commenting out the * text=auto in the .gitattribute file of the repository fixed everything. Its almost like text=auto does not behave the same as autocrlf=true and the latter is disabled if the first is set in the .gitattribute file. But that is not what every guide online seems to indicate.

Dacoity

Commenting out text=auto fixed things for me too. +1 Strange. – Protectorate

Fixed it for me too :o) – Oshiro

I'm on a Mac here and for me the following worked: created a .gitattribute file whith * text=auto inside and saved it to the same directory my .gitconfig or .gitignore_global can be found (most likely your user root). – Leeke

Answer 3

I added both following lines to the config file. The other thing I did was click on the "Staged Files" checkbox and then unclick it, and everything refreshed itself. Good luck.

text = auto 
autocrlf = true

Silique

The irony when you come back and find your own answer and solution. – Silique

Answer 4

Just ran into this issue. A fresh clone would pull several files that were not only uncommitted, but also had many lines of real new code. git reflog showed nothing, it wasn't an actual commit so a detached HEAD was out of question.

After about an hour of investigation we found the cause. One of our *nix developers had, most likely mistakenly, added files to a folder that was the same name as the one intended but had different capitalization. *nix environments were able to handle this new folder easily, but Windows (due to its case-insensitive nature) merged the two folders.

So, for example, if you have two folders, test and Test, each with a file.txt inside and those two file.txt files aren't identical, then Windows will actually copy/replace one of them (not sure which order it clones folders in) thus "changing" the file and creating uncommitted changes on "Test/file.txt" directly after a fresh install.

Example:

test/
--file.txt (with contents of "This is a commit")

Test/
--file.txt (with contents of "This is a commit with some changes")

This will always show new uncommitted changes consisting of adding the words " with some changes" to Test/file.txt when cloning on a Windows machine while *nix-based machines won't have an issue.

This doesn't necessarily address the OP's issue, but directly relates to the question in the title. Hopefully that helps someone out there.

Inconceivable

Answer 5

Normally this line in .gitattribute:

* text=auto

automatically ensures that all files that Git considers to be text will have normalized (LF) line endings in the repository, even when git config core.autocrlf is set to false (default). Therefore Git automatically changes the files according to these rules.

So you've the following possibilities:

• assume the normalization changes are correct (as far they're done to the text files) and simply commit them, e.g.

  $ git diff
  $ git commit -m "Introduce end-of-line normalization" -a
  

• remove/disable auto normalization from the .gitattribute file and reset the files,

• remove the index and re-scan the files, e.g.

  $ rm -v .git/index # Or: git rm --cached -r .
  $ git reset --hard # Rewrite the Git index. Or: git add -u
  

• alternatively, whatever you do, try with force (-f), e.g. git pull origin -f, git checkout master -f, etc.,

• use git command-line instead, since it could be a problem with SourceTree App it-self.

See: Dealing with line endings at GitHub docs.

Nationalism