带有消息描述模糊参数的隐藏显示

Question

我的 windows-bash 控制台和 git 存储库中有这个：

$ git stash list
stash@{0}: WIP on Issue55A: cc3f7ff A3
stash@{1}: On Issue55A: A named stash

然后我想 show/apply/pop 消息（或其中的一部分），我正在尝试这个：

$ git stash show stash^{/named}
fatal: ambiguous argument 'stash^{/named}': unknown revision or 
path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

我读过这个问题：stash@{1} is ambiguous?但是尝试了很多选项来逃避花括号都没有成功。

无论如何我收到错误消息，我认为转义字符没有问题。

更新： 我知道隐藏标准选项 pop/apply/show。但我要求的是使用所有搜索 "message description" 或其中的一部分，如这个答案：我已经用仅一个存储保存对其进行了测试，这有效，但似乎当列表中有多个存储项目时，这不起作用。

Answer 1

Stash 与任何其他 reflog 条目一样，具有 {revision} 索引。

阅读以获取有关 reflog 的一些信息。

`git stash pop`

Remove a single stashed state from the stash list and apply it on top of the current working tree stat

`git stash apply`

Like pop, but do not remove the state from the stash list

`git stash show`

Show the changes recorded in the stash as a diff between the stashed state and its original parent

在您的情况下，您需要使用 stash@{<revision>} 来执行您希望执行的任何隐藏操作。

例如：

git stash show -p stash@{0}

Answer 2

看起来应该可以工作（但不工作，并且不容易工作；我稍后会解释原因）。

作为一般规则，值得尝试将相同的参数直接传递给 git rev-list 以查看 that 是否可以将其解析为 SHA-1。如果这样做，您将再次收到相同的错误消息，但这将确认它不是 git stash 中发生的事情，而是更通用的。

这是问题的根源：git 的 stash 滥用 git 的提交 DAG。（"abuses"这个词可能有点强，但我认为这是有道理的。¹）stash所做的是挂起来自当前分支提示，但不将这些提交放在任何分支上。相反，如果你在两个不同的分支上制作两个存储，你会得到这种安排（假设 stash@{1} 是在 branch1 上制作的，stash@{0} 是在 branch0 上制作的，只是为了一致性和具体性):

... - A - B - C - D     <-branch1
       \          |\
        \         i-w   <-- stash@{1}
         \
          E - F         <-- branch0
              |\
              i-w       <-- stash@{0}

这些 i-w 对是隐藏提交。 i 提交包含索引状态，w 提交包含工作树状态。 Commit w 是合并提交，尽管它与合并无关；每个 w 的第一个父级是分支提交（D 或 F），其第二个是 i 提交。

注意这里只涉及一个git个引用，就是refs/stash。另一件事 git stash 可能被认为是滥用（我认为在这种情况下滥用较少，因为我们已经因 commit-DAG 滥用而陷入困境）是 git 的 reflogs：stashes除了最近的 stash 或 stash@{0} 之外，都是简单的 reflog 条目：stash@{1}、stash@{2} 等等。

在任何情况下，<em>revspec</em>^{/<em>text</em>} 语法指示 git rev-parse 从给定的 revspec 开始，然后向后遍历提交图，寻找其消息包含给定 text 的提交。在你的情况下，这两个藏品无疑是在同一个分支上制作的——类似于：

... - A - B - C - D        <-- branch
                  |\__
                  | \ \
                  |  i-w   <-- stash@{0}
                  |\
                  i-w      <-- stash@{1}

也许——但重点是从这些 work-tree 提交中的 either 开始，向后遍历将检查提交 D，然后提交 C，然后 B，然后 A，依此类推。它永远不会击中 other 存储！即使两个存储袋挂在两个不同的提交中也是如此：

... - A - B - C - D        <-- branch
          |\      |\
          i-w     i-w

从 stash-bag 挂起 D 开始，rev-list 行走是（第二次）w，然后是 D、C、B、A 等。从挂掉的B开始，是（第一个）w，然后是B，然后是A，依此类推。

无论如何，简短的回答是提交文本搜索适用于提交图，而不是引用日志，并且 git 的存储是通过引用日志完成的。如果 git stash 使用不同的方法来保留提交和它们的出身，那可能会使它起作用，但改变这将是不平凡的（特别是你必须在一段时间内支持多个存储形式）。

¹我声称 "abuse" 和这个词的实际滥用本身都是合理的。这个词似乎是合理的，因为这些存储袋并不是真正的合并，它们只是作为合并存储，因此 git stash 代码可以以方便且可恢复的形式保存两个甚至三个工作树。滥用本身似乎是合理的，因为这在拯救树木并使它们方便和可恢复方面做得很好。

带有消息描述模糊参数的隐藏显示

stash show with message description ambiguous argument

git

bash

git-stash

`git stash pop`

`git stash apply`

`git stash show`