Git pull 结果显示“需要更新”和显示为已修改的文件
拉取(到干净的生产类型存储库)时,所有变更集都会遇到,并导致文件显示为已修改并需要提交。 git 日志不显示应该导致这些更改的提交...这些更改只是在没有日志注释的情况下进行拉取,因此它认为它不同步。
拉取结果显示每个文件的“需要更新”消息。
Upon pull (into a clean production-type repo) all the changesets come across and cause the files to appear modified and needing a commit. The git log does not show the commits that should have caused these changes... the changes just pull without the log notes so it believes it's out of sync.
The result of the pull shows "needs update" messages for each file.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我是如何摆脱困境的:
当我不断地测试我的解决方案时,我必须使用...
git reset --hard
这会让你回到原来的状态日志中最近的提交。git clean -fd 会杀死日志中最近提交后未跟踪的文件。
最终我决定需要将有问题的设置文件更改为 chmod 777 并提交权限更改。另一种选择是使用 git config core.filemode false 将 Git 更改为权限不可知模式。在此处阅读更多信息:如何让 Git 忽略文件模式 (chmod) 更改?
然后我进行了拉取以合并更改并让日志随文件,更改权限将有问题的文件返回到 644 并提交...并将其推回到工作主服务器(很高兴这是允许的。)
似乎这是一个错误,权限失败允许合并文件更改集,但日志历史记录不会不反映提交!
顺便说一句:我的 git --version 是 git 版本 1.5.6.5
How I got out of the mess:
As I kept pulling to test my solutions I had to make use of...
git reset --hard
which moves you back to the most recent commit in the log.git clean -fd
which kills off the untracked files since the more recent commit in the log.Eventually I decided I needed to change the offending settings file to
chmod 777
and commit the permission change. Another option would have been to change Git into permission agnostic mode withgit config core.filemode false
Read more here: How do I make Git ignore file mode (chmod) changes?Then I did a pull to merge the changes and have the log update along with the files, changed the permission of the offending file back to 644 and commit that... and pushed it back to the working master (glad that's allowed.)
Seems like this is a bug that having a permission failure allows the file changesets to be merged but the log history doesn't reflect the commits!!!
BTW: My
git --version
isgit version 1.5.6.5
如Git 项目所示,当 Git 尝试调整 eol 样式时,可能会发生这种情况对于在 Unix 上开发并在 Windows 上克隆的项目:
请参阅此 所以回答更多。
As illustrated in this Git project, this can happen when Git tries to adjust eol style for projects developed on Unix, and cloned on Windows:
See this SO answer for more.