git reset --hard之后没有暂停的更改

Question

标题说明了一切.

之后git reset --hard,git status给我Changes not staged for commit:部分内的文件.

我也尝试了git reset .,git checkout -- .并且git checkout-index -f -a无济于事.

那么,我怎样才能摆脱那些未分阶段的变化呢？

这似乎只打击Visual Studio项目文件.奇怪的.请参阅此粘贴:http://pastebin.com/eFZwPn9Z.这些文件的特殊之处在于.gitattributes我有:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

此外,autocrlf在我的全局中设置为false .gitconfig.这可能是某种相关的吗？

Answer 1

我有同样的问题,它与.gitattributes文件有关.但是,未在文件中指定导致问题的文件类型.gitattributes.

我只需运行即可解决问题

git rm .gitattributes
git add -A
git reset --hard

Answer 2

解决!!!

我已经使用以下stpes解决了这个问题

1)从Git的索引中删除每个文件.

git rm --cached -r .

2)重写Git索引以获取所有新行结尾.

git reset --hard

解决方案是git网站https://help.github.com/articles/dealing-with-line-endings/上描述的步骤的一部分

Answer 3

Git不会重置不在存储库上的文件.所以你可以:

$ git add .
$ git reset --hard

这将暂存所有更改,这将导致Git知道这些文件,然后重置它们.

如果这不起作用,您可以尝试存储和删除更改:

$ git stash
$ git stash drop

Answer 4

如果您使用Git for Windows,这可能是您的问题

我有同样的问题,藏匿,硬重置,清洁,甚至所有这些仍然留下了变化.结果是问题的是git没有正确设置的x文件模式.这是一个使用git for windows的"已知问题".本地更改以gitk和git状态显示为旧模式100755新模式100644,没有任何实际文件差异.

修复是忽略文件模式:

git config core.filemode false

更多信息在这里

Answer 5

好的,我有点解决了这个问题.

它似乎是.gitattributes文件,包含:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

使项目文件显示为未分级.我不知道为什么会这样,我真的希望有人知道git的方式会给我们一个很好的解释.

我的修复是删除这些文件,并添加autocrlf = false下[core]在.git/config.

这与前一个配置完全不同,因为它需要每个开发人员autocrlf = false.我想找一个更好的解决方案.

编辑:

我对这些有罪的线路进行了评论,对它们进行了评论并且有效.什么......我甚至不......

Answer 6

可能的原因#1 - 线路结束标准化

可能发生这种情况的一种情况是,当有问题的文件被检入存储库时,没有正确的行结尾配置(1)导致存储库中的文件具有错误的行结尾或混合行结尾.要确认,请确认git diff仅显示行结尾的更改(默认情况下可能不会显示这些更改,请尝试git diff | cat -v将回车符视为文字^M字符).

随后,有人可能添加了一个.gitattributes或修改了core.autocrlf设置以标准化行结尾(2).基于.gitattributes或全局配置,Git已对您的工作副本应用了本地更改,这些更改应用了请求的行结束规范化.不幸的是,由于某些原因git reset --hard,不会撤消这些行规范化更改.

解

重置本地行结尾的解决方法无法解决问题.每当git"看到"文件时,它都会尝试重新应用规范化,从而导致同样的问题.

最好的选择是让git应用它想要的规范化,通过规范化repo中的所有行结尾来匹配.gitattributes,并提交这些更改 - 请参阅尝试使用git filter-branch修复行结尾,但没有运气.

如果你真的想尝试手动恢复文件的更改,那么最简单的解决方案似乎是擦除修改后的文件,然后告诉git恢复它们,虽然我注意到这个解决方案似乎不能始终如一地工作100%时间(警告:如果修改后的文件有除行尾之外的更改,请不要运行此命令!!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

请注意,除非您在某个时刻对存储库中的行结尾进行规范化,否则您将继续遇到此问题.

可能的原因#2 - 案例不敏感

第二个可能的原因是Windows或Mac OS/X上的不区分大小写.例如,假设存储库中存在以下路径:

/foo/bar

现在有人在Linux上提交文件/foo/Bar(可能是由于构建工具或创建该目录的东西)并推送.在Linux上,这实际上是两个独立的目录:

/foo/bar/fileA
/foo/Bar/fileA

在Windows或Mac上检查此repo可能会导致修改fileA无法重置,因为在每次重置时,Windows上的git都会检出/foo/bar/fileA,然后因为Windows不区分大小写,会覆盖fileAwith 的内容/foo/Bar/fileA,从而导致它们被"修改".

另一种情况可能是存在于repo中的单个文件,当在不区分大小写的文件系统上检出时,它们会重叠.例如:

/foo/bar/fileA
/foo/bar/filea

可能存在可能导致此类问题的其他类似情况.

对不区分大小写的文件系统的git应该真正检测到这种情况并显示一条有用的警告消息,但它目前没有(这可能会在未来发生变化 - 请参阅git.git邮件列表中的此讨论和相关的建议补丁).

解

解决方案是将git索引中的文件和Windows文件系统上的大小写对齐.这可以在Linux上完成,它将显示事物的真实状态,或者在Windows上使用非常有用的开源实用程序Git-Unite.Git-Unite会将必要的大小写更改应用于git索引,然后可以将其提交到repo.

(1)这是最有可能使用Windows的人,没有任何.gitattributes有问题的文件定义,并使用默认的全局设置为core.autocrlf它false(见(2)).

(2)http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Answer 7

如果其他答案不起作用，请尝试添加文件，然后重设

$ git add -A
$ git reset --hard

就我而言，这在git跟踪大量空文件时很有帮助。

Answer 8

造成这种情况的另一个原因可能是不区分大小写的文件系统.如果您的仓库中的多个文件夹位于同一级别,其名称仅因大小写而异,则会受到此影响.使用其Web界面(例如GitHub或VSTS)浏览源存储库以确保.

有关更多信息,请访问:https://stackoverflow.com/a/2016426/67824

Answer 9

您可以stash删除您的更改，然后删除存储：

git stash
git stash drop

Answer 10

这些方法都不适合我，唯一的解决方案是取消整个 repo 并重新克隆它。这包括隐藏、重置、添加然后重置、clrf 设置、区分大小写等。 叹..

Answer 11

运行清理命令：

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Answer 12

我相信 Windows 版 git 存在一个问题，即 git 在签出时随机写入错误的行结尾，唯一的解决方法是签出其他一些分支并强制 git 忽略更改。然后检查您真正想要工作的分支。

git checkout master -f
git checkout <your branch>

请注意，这将放弃您可能有意进行的任何更改，因此仅当您在结帐后立即遇到此问题时才执行此操作。

编辑：我第一次可能真的很幸运。结果换了分支后又被咬了。事实证明，更改分支后 git 报告为已修改的文件正在更改。（显然是因为 git 没有一致地正确地将 CRLF 行结尾应用于文件。）

我更新到了 Windows 的最新 git，希望问题已经消失。