【问题标题】:Git submodules reference is not a treeGit子模块引用不是一棵树
【发布时间】:2011-10-05 10:13:11
【问题描述】:

这里的一位开发人员运行了我们推荐的 git 使用步骤,但丢失了一个子模块提交。我知道这个错误意味着她推入了超级项目而不是子模块,但她否认了这一点,并且有她向我展示的命令历史记录。以下是似乎导致此问题的步骤。我想了解如何告诉她以后避免这种情况。

  • 她致力于子模块和超级项目。
  • 她在她的分支上拉了最新的。这导致了子模块冲突,没有真正的内容冲突
  • 她在超级项目中运行了 git commit -a 来解决它。 (了解这种类型的冲突也会很有帮助)。
  • 她从另一个分支运行了一个合并,并在两个地方都提交了。
  • 她运行了一个全局推送,将 cd 放入每个子模块,运行推送,然后在超级项目中运行推送。

此时,她在子模块中原提交中提交的工作从git log中消失了。

【问题讨论】:

  • reference is not a tree 错误发生在什么时候?
  • 在我上面概述的步骤结束时,我克隆了她在拉取和合并之前所做的超级项目中的提交,然后我尝试检查子模块中的提交 ID。这是我得到不是树错误的时候。然而,她注意到在她完成拉/合并/推后,她的更改立即从子模块中消失了。 git log 输出现在根本没有列出在子模块中所做的提交。

标签: git git-merge git-submodules git-commit git-pull


【解决方案1】:

我想当她解决子模块冲突时提交丢失了。可以按照this question中的说明进行检索。

或者运行

gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )

(来自this question

仅在原始 repo 上执行(因为git clone 将删除悬空提交),并在之前对其进行备份。

【讨论】:

  • 我同意你的观点,但是我们如何帮助那些刚接触 git 的开发人员不做这种事情呢?是什么导致了这样的子模块冲突?
  • 这可能是另一个问题,我对子模块不是很了解...但是在合并诸如子模块之类的野兽时必须非常小心。
  • 顺便说一句,她恢复了提交吗?
  • 不,她没有等我上班。她重新实施了这些更改。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-12-20
  • 1970-01-01
  • 2018-07-02
  • 1970-01-01
  • 1970-01-01
  • 2019-06-07
相关资源
最近更新 更多