【问题标题】:`git stash apply` deleted a random dir from my working copy`git stash apply` 从我的工作副本中删除了一个随机目录
【发布时间】:2019-10-14 02:16:15
【问题描述】:

我第一次尝试git stash save。它工作得很好。然后我尝试了git stash apply,当我未提交的更改被恢复时,另一个效果是我的工作副本根目录中的一个随机目录被删除了。我不知道为什么它选择了那个确切的目录,在根目录下还有很多其他类似的目录。

git stash save 输出:

Saved working directory and index state WIP on clipping: cfeac4b - applying the solution from http://stackoverflow.com/questions/40385482/why-cant-i-use-opengl-es-3-0-in-qt
HEAD is now at cfeac4b - applying the solution from http://stackoverflow.com/questions/40385482/why-cant-i-use-opengl-es-3-0-in-qt

缩短git stash apply 输出:

Removing debug_stencil_not_working/textureandlight.js
Removing debug_stencil_not_working/qtlogo.png
[... more removes here ...]
On branch clipping
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   documentation/textureSize_missing.txt

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    ../debug_stencil_not_working/qtlogo.png
        deleted:    ../debug_stencil_not_working/textureandlight.js
        [... more deleted files here ...]
        modified:   main.cpp
        modified:   main.qml
        [... more modified files here ...]

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        ../dbg_repeater/dbg_repeater.pro.user
        debug_stencil_not_working/
        [... more files and dirs here ...]

注意:被删除的目录是一个提交和推送的目录。它没有未提交的本地更改。

知道为什么这个随机目录被删除了吗?

另外,如何恢复这个目录?当我在 github Web 界面中浏览到根目录时,它就在那里。但是我尝试了git pull origin clipping,但它并没有将该目录拉回我的工作副本中。

编辑:我想出了如何恢复它。在 TortoiseGit 上下文菜单中,我选择了“Diff”,在列表中删除的文件被列为“丢失”。我选择了它们,右键单击它们,然后选择“还原”。仍然不知道为什么该目录首先被删除。

【问题讨论】:

  • 鉴于您使用了apply(不是drop),存储应该仍然存在,因此您可以使用git stash show 来检查它,也许使用-p 来查看详细的差异。这实际上只显示了工作树提交,而不是索引提交,所以如果你做了一些单独的暂存与脏工作树,可能需要另一个步骤。
  • @torek:谢谢,我应该在git stash show 的输出中寻找什么?
  • 查看是否有Deleted 文件。如果此处没有显示,请尝试git diff --name-status stash^1 stash,它将存储对的基数 (stash^1) 与索引提交 (stash) 进行比较,并查看是否有任何 那些 显示为Deleted.
  • @torek:好的,我几天前放弃了我在问题中提到的存储,所以我不能用它来检查这个。我再次尝试git stash save,然后是git stash apply,但没有删除任何文件夹。所以我们不能重现这个。不过,我想知道为什么会发生这种情况。
  • 可能仍然能够找到它(Git 默认不会清除小于 14 天的对象,即使那样它也只会删除一次未引用的对象它运行修剪代码)但它可能不值得太努力搜索。如果您确实想搜索,请参阅git stash 文档末尾的建议。

标签: git git-stash


【解决方案1】:

我遇到了同样的问题,我偶然发现,在其中一个 .gitignore 文件中,有一个包含该目录的条目,该条目在表单中被删除: 目录/* 或目录/** 仅当目录后跟通配符字符时才会出现这种情况。

在我的情况下删除该行解决了问题(无论如何它不应该存在)

对不起,我无法解释为什么 git 会这样做,也许其他人可以。

【讨论】:

  • 被删除的目录的根目录中是否包含错误的 .gitignore 文件?此外,如果要删除的目录名为 foo,那么相关行是否类似于 foo/*
  • 错误的.gitignore 不包含在被删除的目录的根目录中。
  • 并且该条目看起来像您建议的那样 (bin/bin-ext/integration/*)
  • 好的,我在已删除(后来恢复)的目录中的 .gitignore 中没有发现任何有问题的条目,并且在 repo 树的更深处没有包含 .gitignore 文件的目录。所以看来我的问题出在其他地方。不过谢谢!
【解决方案2】:

仍然不知道为什么目录首先被删除。

一个可能的原因是设置了GIT_DIR

git stash apply”在辅助工作树的子目录中失败 正确访问工作树,已在 Git 2.24(2019 年第四季度)中更正。

参见 Johannes Schindelin (dscho)commit dfd557c(2019 年 10 月 4 日)。
(由 Junio C Hamano -- gitster -- 合并到 commit 66102cf,2019 年 10 月 11 日)

stash apply:即使在工作树的子目录中也能正确报告状态

当 Git 想要在设置了 GIT_DIR 的情况下在工作树的子目录中生成子 Git 进程时,我们需要明确指定工作树的顶级目录,因为它无法被发现:

  • 当前目录不是的顶级目录 工作树,以及
  • 不在GIT_DIR的父目录内。

这解决了git stash apply 在工作树的子目录中运行时会报告几乎所有已删除或未跟踪的内容的问题。

为了确保我们不会引入“反向问题”,即当 GIT_WORK_TREE 已定义但 GIT_DIR 未定义时,我们只需确保两者都已设置。

【讨论】:

    猜你喜欢
    • 2017-06-22
    • 1970-01-01
    • 2011-12-24
    • 1970-01-01
    • 2020-06-01
    • 2013-02-23
    • 2014-06-06
    • 1970-01-01
    相关资源
    最近更新 更多