SourceTree应用程序说，即使对于新克隆的存储库，未提交的更改也可能是错误的？ [英] SourceTree App says uncommitted changes even for newly-cloned repository - what could be wrong?
问题描述
使用 Atlassian 将远程git存储库克隆到 SourceTree 。即使在工作树中没有真正修改过文件，Atlassian在未提交更改下立即列出了一堆文件。每个文件显示的移除和添加的行数都相同，并且此计数等于文件中行的总数。这会以某种方式暗示我们正在碰到某种行结束问题。
然而，存储库的 .gitattribute 包含
＃设置默认行为，以防用户没有设置core.autocrlf。
* text = auto
每个GitHub文章处理换行符应显式地 core.autocrlf true为存储库。然而，〜/ .gitconfig 包含 autocrlf = true 。
如果试图将修改后的文件还原回到先前的提交，则不起作用。相同的文件仍被视为未提交。
存储库已被克隆到多个位置，并确保没有文件位于相同路径中，以确保SourceTree或git不记得旧文件。
存储库与Windows，Linux和OSX盒子配合使用。这个问题只出现在OSX中。
SourceTree / repository / git安装中仍然有问题？
更新＃1，2013年4月20日
由于仍有错误，所以<
从SourceTree控制台（OSX）
$ c $> git config --list pre>
core.excludesfile = / Users / User / .gitignore_global
core.autocrlf =输入
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
核心。 logallrefupdates = true
core.ignorecase = true
core.autocrlf = true
这里是Windows端的相应输出：
core.symlink s = 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
核心。 filemode = false
core.bare = false
core.logallrefupdates = true
core.symlinks = false
core.ignorecase = true
core.hidedotfiles = dotGitOnly
core.eol = native
core.autocrlf = true
完整<$ c
＃设置默认行为，如果用户不知道没有core.autocrlf集合。
* text = auto
* .php text
* .twig text
* .js text
* .html text diff = html
* .css文本
* .xml文本
* .txt文本
* .sh文本eol = lf
控制台文本
* .png二进制
* .jpg二进制
* .gif二进制
* .ico二进制
* .xslx二进制
我是SourceTree开发人员之一（我实际上开发了Mac版本的产品），所以希望我能有所帮助。
Windows机器在提交时将CRLF转换为LF，并在检出时将LF转换为CRLF。 autocrlf 确保库中的所有内容都是LF。选项 text = auto 是我们感兴趣的选项，但它在文档中说：
设置文本时到自动时，该路径被标记为自动结束标准化。如果git决定内容是文本，那么它的行结束符会在签入时标准化为LF。
所以你在签入时看到它会说嘿，我需要规范这些行尾，因为它们不是LF格式，而是CRLF。并因此修改您的工作副本，以完成预期要完成的工作。通常在Mac / Linux上，你不需要规范化，因为一切都在LF中，但是Git会做一个检查，因为你可能已经从以前在Windows上开发过的存储库检出，或者可能在使用CRLF的编辑器中检出而不是LF。
所以，简而言之，您可能希望重新提交所有这些文件，因为它们应该是LF格式，但也要确保 autocrlf = true （编辑，总是为true！），正如它在文档中所说的那样：
如果您只是想在工作目录中拥有CRLF行结束符，而不管您使用的是哪个存储库，则可以在不更改任何属性的情况下设置配置变量core.autocrlf。
尽管设想前面的引用是为特定的存储库以及全局设置 autocrlf 。
希望这有些帮助，如果没有，请随时提出更多问题！
下面是一个很好的SO post re：行结尾：为什么我应该在Git中使用core.autocrlf = true？
编辑
基于上述答案，我们需要在这里确定几件事情。
- 您已经在
.git / config
- 如果您想保留CRLF行尾，然后设置
autocrlf = true - 您不希望自动转换行结尾（导致所有文件立即处于修改状态），然后将
text选项设置为未设置。如果全局git配置将其设置为您不想要的值，则添加此选项。 - 如果您在Windows和Mac上为项目工作，那么最好是
text = auto并确保LF在整个电路板上使用。这就是为什么这样的问题在蔓延;因为你的git配置不同，或者当你的Mac假设LF时，Windows上的初始项目/ git设置假定为CRLF。
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
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
textoption tounset. 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=autoand 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.
这篇关于SourceTree应用程序说，即使对于新克隆的存储库，未提交的更改也可能是错误的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
