git SourceTree App 表示即使是新克隆的存储库也未提交的更改 - 有什么问题？

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

提问by Ville Mattila

A remote git repository is just clonedto 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.

远程git仓库只是克隆使用本地箱Atlassian的SourceTree。即使工作树中没有真正修改过文件，Atlassian 也会立即在“未提交的更改”下列出一堆文件。每个文件在删除和添加时显示相同的行数，此计数等于文件中的总行数。这会以某种方式暗示我们遇到了某种行尾问题。

However, the repository's .gitattributecontains

但是，存储库的.gitattribute包含

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

that per GitHub article Dealing with Line Endingsshould make explicitly core.autocrlftrue for the repository. However also ~/.gitconfigcontains autocrlf = true.

每个 GitHub 文章处理行尾应该明确地core.autocrlf为存储库设置为真。然而也~/.gitconfig包含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.

存储库已被克隆到多个位置并确保没有文件位于同一路径中，以确保 SourceTree 或 git 不会记住旧文件。

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

该存储库与 Windows、Linux 和 OSX 机器协作。此问题仅出现在 OSX 中。

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

SourceTree/repository/git 设置中还有什么问题？

---

---

Update #1, 20. Apr 2013

更新 #1, 20。2013 年 4 月

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

由于仍然有问题，这里是git config --list.

From SourceTree console (OSX)

从 SourceTree 控制台 (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:

这是来自 Windows 端的相应输出：

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 .gitattributesfor the repository in question

并且完整.gitattributes的有问题的存储库

# 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

采纳答案by Kezzer

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

我是 SourceTree 的开发人员之一（实际上，我开发了该产品的 Mac 版本），所以希望我能有所帮助。

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

Windows 机器在提交时将 CRLF 转换为 LF，在签出时将 LF 转换为 CRLF。autocrlf确保存储库中的所有内容都是 LF。该选项text = auto是我们感兴趣的选项，但正如文档中所说：

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.

当 text 设置为“auto”时，路径被标记为自动行尾规范化。如果 git 决定内容是文本，则在签入时将其行尾规范化为 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. 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.

所以你在签入时看到它会说“嘿，我需要标准化这些行尾，因为它们不是 LF 格式，而是 CRLF。” 从而修改您的工作副本以完成预期的工作。通常在 Mac/Linux 上你不需要标准化，因为一切都在 LF 中，但 Git 会做一个检查，因为你可能已经从以前在 Windows 上开发的存储库中检出，或者可能在使用 CRLF 的编辑器中检出而不是 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:

简而言之，您可能希望重新提交所有这些文件，因为它们应该是 LF 格式，但还要确保autocrlf = true（编辑，始终为 true！）在您的 Windows 存储库中，如文档中所述：

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.

如果您只想在工作目录中使用 CRLF 行结尾，而不管您使用的是哪个存储库，则可以设置配置变量“core.autocrlf”而无需更改任何属性。

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

虽然想象之前的引用是在autocrlf为特定存储库以及全局设置时。

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?

这是一个很好的 SO 帖子：行结尾：为什么我应该在 Git 中使用 core.autocrlf=true？

---

---

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 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=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.

• 你已经在你的文件中设置了相关的 git 选项 .git/config
• 如果要保留 CRLF 行结尾，请设置 autocrlf=true
• 如果在签出存储库时不希望自动转换行尾（导致所有文件立即处于“已修改”状态），则将该text选项设置为unset. 如果全局 git 配置将其设置为您不想要的值，请添加此选项。
• 如果您在 Windows 和 Mac 上为一个项目工作，那么最好拥有text=auto并确保全面使用 LF。这就是为什么会出现这样的问题；因为您的 git 配置不同，或者因为当您的 Mac 假定为 LF 时，Windows 上的初始项目/git 设置假定为 CRLF。

回答by Adam Nofsinger

I still don't understand it 100%, but for us the issue was the * text=autoin the .gitattributefile in the repository. I checked, and we for sure have core.autocrlf=trueset 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.

我仍然没有 100% 理解它，但对我们来说，问题出* text=auto在.gitattribute存储库中的文件中。我检查过，我们肯定已经core.autocrlf=true在 Windows PC 上为我的用户设置的每个地方都设置了它。我知道这也不是 SourceTree 问题，因为 TortoiseGit 和 Windows Git (msysgit) 对于这个存储库都有相同的“问题”。非常奇怪的行为 - 我会克隆 repo 一次并立即看到 11 个“不同”的文件，然后我会删除并重新开始，下一个克隆将有 14 个“不同”的文件。

Commenting out the * text=autoin the .gitattributefile of the repository fixed everything. Its almost like text=autodoes not behave the same as autocrlf=trueand the latter is disabled if the first is set in the .gitattributefile. But that is not what every guide online seems to indicate.

注释掉* text=auto的在.gitattribute库固定的一切文件。它几乎就像text=auto不一样，autocrlf=true如果在.gitattribute文件中设置了第一个，则后者被禁用。但这并不是每个在线指南似乎都表明的内容。

回答by vr_driver

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

回答by kenorb

Normally this line in .gitattribute:

通常这一行在.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.autocrlfis set to false(default). Therefore Git automatically changes the files according to these rules.

自动确保 Git 认为是文本的所有文件都将在存储库中具有规范化 (LF) 行结尾，即使git config core.autocrlf设置为false（默认）。因此 Git 会根据这些规则自动更改文件。

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 .gitattributefile 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 gitcommand-line instead, since it could be a problem with SourceTree App it-self.

• 假设规范化更改是正确的（就它们对文本文件所做的那样）并简单地提交它们，例如

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

• 从.gitattribute文件中删除/禁用自动规范化并重置文件，

• 删除索引并重新扫描文件，例如

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

• 另外，无论你做什么，尝试用武力（-f），例如git pull origin -f，git checkout master -f等等，

• 请改用git命令行，因为 SourceTree App 本身可能存在问题。

See: Dealing with line endingsat GitHub docs.

请参阅：在 GitHub 文档中处理行尾。

回答by Colt McCormack

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.

刚遇到这个问题。一个新的克隆会提取多个文件，这些文件不仅未提交，而且还有许多真正的新代码行。git reflog 什么也没显示，它不是实际提交，因此分离的 HEAD 是不可能的。

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.

经过大约一个小时的调查，我们找到了原因。我们的一位 *nix 开发人员很可能是错误地将文件添加到与预期名称相同但大小写不同的文件夹中。*nix 环境能够轻松处理这个新文件夹，但 Windows（由于其不区分大小写的性质）合并了这两个文件夹。

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.

因此，例如，如果您有两个文件夹 test 和 Test，每个文件夹里面都有一个 file.txt 并且这两个 file.txt 文件不相同，那么 Windows 实际上会复制/替换其中一个（不确定它的顺序）克隆文件夹）从而“更改”文件并在全新安装后直接在“Test/file.txt”上创建未提交的更改。

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.

当在 Windows 机器上克隆时，这将始终显示新的未提交的更改，包括将单词“with some changes”添加到 Test/file.txt 而基于 *nix 的机器不会有问题。

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

这不一定解决 OP 的问题，但与标题中的问题直接相关。希望这可以帮助那里的人。