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: 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 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. If git decides that the content is text, its line endings are normalized to LF on checkin. When text is set to "auto", the path is marked for automatic end-of-line normalization. The option text = auto is the one we're interested in though as it says in the docs: autocrlf makes sure everything is LF within the repository. Windows machines convert CRLF to LF when committing and LF to CRLF when checking out. I'm one of the SourceTree developers (I develop the Mac version of the product, actually), so hopefully I can be of some help. gitattributes for the repository in question # Set default behaviour, in case users don't have tocrlf set. Here is corresponding output from Windows side: core.symlinks=falseĪnd full. =/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED" What could still be wrong in the SourceTree/repository/git setup?Īs there is still something wrong, here are partial outputs of git config -list.įrom SourceTree console (OSX) core.excludesfile=/Users/User/.gitignore_globalĭ=opendiff "$LOCAL" "$REMOTE" ![]() The repository is collaborated with Windows, Linux and OSX boxes. 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. ![]() Same files are still seen as uncommitted. If the modified files are tried to be "reverted" back to previous commit, there is no effect. ![]() However also ~/.gitconfig contains autocrlf = true. That per GitHub article Dealing with Line Endings should make explicitly tocrlf true for the repository. gitattribute contains # Set default behaviour, in case users don't have tocrlf set. This would somehow give a hint that we're hitting some kind of line ending problem. Each file shows same line count both as removed and added, and this count equals to the total count of lines in the file. Even no files have really been modified in the work tree, Atlassian lists a bunch of files right away under "Uncommitted changes". SourceTree App says uncommitted changes even for newly-cloned repository - what could be wrong?Ī remote git repository is just cloned to a local box using Atlassian SourceTree.
0 Comments
Leave a Reply. |