git line endings - 无法存储,重置,现在无法通过虚假行结尾提交

 数字货币交易所贺顾问 发布于 2023-02-02 19:59

我有一个回购我添加了gitattributes它并正在努力它.我通过Dropbox将它同步到另一台机器.当我把它打开到另一台机器时,一堆文件突然出现在未分区的区域作为总差异(所有文件都是一个巨大的差异,这意味着行结束差异) - 我的crlf结局基本上是.* text=auto我在Windows上工作.我试图隐藏更改,重置分支等.最后我决定提交文件然后做了一些其他提交我想在行结束提交之前重新排序(和压缩).当我尝试变基时,我得到一个:

error: Your local changes to the following files would be overwritten by merge
        # those same files
Please, commit your changes or stash them before you can merge.
Aborting
Could not apply 89b25b81fff1a1e7893319e123aaaca9c4162a95... 

当然藏匿不起作用

这是一个错误吗?

有关:

从SVN迁移到git后,如何解决行结束问题?(是的,我的是一个git-svn克隆,但我不认为它真的很重要)

似乎无法放弃Git的变化(是的,我想知道为什么)

git认为文件已经改变

有人可以向我解释git diff在这里看到的区别吗?

编辑与机器无关 - 在同一台机器上,一些(......)操作只是使这些文件(它们在.gitattributes文本中)出现在"已更改"部分.似乎存在的唯一解决方法是:

git rm --cached -r .
git reset --hard

小心使用

编辑:hack上面转移到别名状态:

[alias]
     crlf = !git rm -r . --cached -q && git reset --hard

更新2015.09.30:我在一个NTFS分区中有一个git repo,我在Windows 7中使用并在双启动环境中使用linux.当我关闭窗口时,我启动到拱门两个文件(html)显示为总差异(行结束差异).上面的解决方法不起作用 - 除非你多次应用它来刷新gui ...

我的.gitattributes:

* text=auto

*.py text diff=python
*.html text
.project text
*.pkl -text

# M$ files
*.bat text eol=crlf

# UNIX files
**/generate_second_post text eol=lf

# git files - have them with LF, as I edit them via the shell (echo etc)
*.gitignore text eol=lf
*.gitattributes text eol=lf

注意:linux会让我提交,切换分支等但不会让我反驳 - 加上那些差异总是出现在gitk/git gui中.

2018/12/14转移到mac,我的解决方法不再起作用了.我在git邮件列表中发了一条消息:https://marc.info/? l = git&m = 154482149623324&w = 2

我们希望这会得到一些关注

$ git --version
git version 2.19.2

Mr_and_Mrs_D.. 11

最后,经过5年的努力,TorstenBögershausen终于有了一个完整的答案。

调试此eol情况的方法是使用--eol开关对TorstenBögershausen添加的git ls文件进行调查。原来有问题的文件是使用CRLF提交的,而稍后添加的.gitattributes文件为此文件指定text了文件。这导致“非法状态”。对于旧的提交,什么也没做。

应该做的是git add --renormalize .添加正确的(lf)行尾的文件,然后重新设置--hard以使这些行尾出现在工作树中。

但是,现在这对旧的提交将无济于事(处于这种非法状态的提交,因此在文件之间以错误的行尾提交和gitattributes提交之间)-检查这些提交可能会导致那些不可重置的更改。@iKlsR 的答案提供了此修复程序:

$ cat .git/info/attributes
"Mopy/Docs/Bash Readme Template.html" -text

其原因是认为:

在确定将哪些属性分配给路径时,Git会参考$ GIT_DIR / info / attributes文件(优先级最高)、. gitattributes文件与所讨论路径位于同一目录中,以及其父目录直至该目录的顶层。工作树[ ect ]

(强调我的)

只要确保重新规范化之后添加该行,否则文件就不会添加到重新规范化提交中!

1 个回答
  • 最后,经过5年的努力,TorstenBögershausen终于有了一个完整的答案。

    调试此eol情况的方法是使用--eol开关对TorstenBögershausen添加的git ls文件进行调查。原来有问题的文件是使用CRLF提交的,而稍后添加的.gitattributes文件为此文件指定text了文件。这导致“非法状态”。对于旧的提交,什么也没做。

    应该做的是git add --renormalize .添加正确的(lf)行尾的文件,然后重新设置--hard以使这些行尾出现在工作树中。

    但是,现在这对旧的提交将无济于事(处于这种非法状态的提交,因此在文件之间以错误的行尾提交和gitattributes提交之间)-检查这些提交可能会导致那些不可重置的更改。@iKlsR 的答案提供了此修复程序:

    $ cat .git/info/attributes
    "Mopy/Docs/Bash Readme Template.html" -text
    

    其原因是认为:

    在确定将哪些属性分配给路径时,Git会参考$ GIT_DIR / info / attributes文件(优先级最高)、. gitattributes文件与所讨论路径位于同一目录中,以及其父目录直至该目录的顶层。工作树[ ect ]

    (强调我的)

    只要确保重新规范化之后添加该行,否则文件就不会添加到重新规范化提交中!

    2023-02-02 20:06 回答
撰写答案
今天,你开发时遇到什么问题呢?
立即提问
热门标签
PHP1.CN | 中国最专业的PHP中文社区 | PNG素材下载 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有