40

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

但是，存储库.gitattribute包含

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

根据 GitHub 文章处理行尾应该明确地core.autocrlf适用于存储库。不过也~/.gitconfig包含autocrlf = true。

如果尝试将修改后的文件“还原”回之前的提交，则没有效果。相同的文件仍被视为未提交。

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

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

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

更新 #1，2013 年 4 月 20 日

由于仍有问题，这里是部分输出git config --list。

从 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

以下是 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

并且完整.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
4

5 回答 5

39

我是 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（编辑，始终为真！）在您的 Windows 存储库中，如文档中所述：

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

尽管想象先前的报价是在autocrlf为特定存储库以及全局设置时。

希望对您有所帮助，如果没有，请随时提出更多问题！

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

编辑

基于上面的答案，我们需要在这里确定一些事情。

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

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

注释掉存储库文件中的所有内容* text=auto。如果在文件中设置了第一个，则它的行为.gitattribute几乎与后者不同。但这并不是每个在线指南似乎都表明的。text=autoautocrlf=true.gitattribute

于 2015-01-23T18:33:50.397 回答
1

我将以下两行添加到配置文件中。我做的另一件事是单击“暂存文件”复选框，然后取消单击它，一切都会自行刷新。祝你好运。

text = auto 
autocrlf = true
于 2015-10-30T03:08:39.183 回答
0

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

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

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

例子：

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

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

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

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

于 2013-12-18T20:57:37.053 回答
0

通常这一行在.gitattribute：

* text=auto

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

所以你有以下可能性：

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

    $ 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

  • 或者，无论您做什么，都尝试使用 force ( -f)，例如git pull origin -f,git checkout master -f等，

  • 改用git命令行，因为它可能是 SourceTree App 本身的问题。

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

于 2016-01-15T14:28:54.413 回答