SourceTree App即使对于新克隆的存储库也说未提交的更改 - 可能出错?

时间:2013-04-11 20:39:28

标签: git end-of-line atlassian-sourcetree

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

但是,存储库的.gitattribute包含

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

根据GitHub文章Dealing with Line Endings应该对存储库显式core.autocrlf为真。不过,~/.gitconfig也包含autocrlf = true

如果尝试将修改后的文件“还原”回上一次提交,则无效。相同的文件仍被视为未提交。

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

存储库与Windows,Linux和OSX盒子协作。此问题仅出现在OSX中。

SourceTree / repository / git设置中可能还有什么问题?


2013年4月20日更新#1。

由于仍有问题,以下是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

5 个答案:

答案 0 :(得分:38)

我是SourceTree开发人员之一(实际上我开发了该产品的Mac版本),所以希望我可以提供一些帮助。

Windows机器在提交时将CRLF转换为LF,在签出时将CR转换为CRLF。 autocrlf确保存储库中的所有内容都是LF。选项text = auto是我们感兴趣的选项says in the docs

  

当文本设置为“auto”时,路径将标记为自动行结束标准化。如果git决定内容是文本,则在签入时将其行结尾标准化为LF。

所以你在签到时会看到它会说“嘿,我需要规范化这些行结尾,因为它们不是LF格式,而是CRLF。”并因此修改您的工作副本以完成预期的工作。通常在Mac / Linux上你不需要规范化,因为一切都在LF中,但是Git会检查,因为你可能已经从以前在Windows上开发的存储库中检出过,或者可能在使用CRLF的编辑器中检出而不是LF。

因此,简而言之,您可能希望重新提交所有这些文件,因为它们应该是LF格式,但也要确保在Windows资源库中autocrlf = true(编辑,始终为true!)它在文档中说:

  

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

虽然想象之前的引用是为特定存储库和全局存储设置autocrlf

希望有一些帮助,如果没有,请随时提出更多问题!


这是一个很好的SO帖子:行结尾:Why should I use core.autocrlf=true in Git?


修改

根据上述答案,我们需要确定一些事项。

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

答案 1 :(得分:11)

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

注释掉存储库的* text=auto文件中的.gitattribute修复了所有问题。它几乎与text=auto的行为不同autocrlf=true,如果第一个在.gitattribute文件中设置,后者将被禁用。但这不是每个在线指南似乎都表明的内容。

答案 2 :(得分:1)

我在配置文件中添加了以下两行。我做的另一件事是单击“Staged Files”复选框然后取消选中它,一切都自行刷新。祝好运。

text = auto 
autocrlf = true

答案 3 :(得分: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添加“带有一些更改”字样,而基于* nix的计算机不会出现问题。

这不一定解决OP的问题,而是直接与标题中的问题相关。希望这可以帮助那些人。

答案 4 :(得分: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
    
  • 或者,无论你做什么,都要强行(-f),例如git pull origin -fgit checkout master -f等,

  • 使用git命令行,因为它可能是SourceTree App自身的问题。

请参阅GitHub文档中的Dealing with line endings