我在我的windows-bash控制台和git存储库中有这个：
$ git stash list
stash@{0}: WIP on Issue55A: cc3f7ff A3
stash@{1}: On Issue55A: A named stash
然后我想显示/应用/弹出消息（或部分消息），我正在尝试这个：
$ 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?但是没有运气尝试很多选项来逃避大括号。
无论如何，我得到错误信息，我认为转义字符没有问题。
更新： 我知道stash标准选项pop / apply / show。但我要求的是使用所有这些搜索“消息描述”或其中的一部分，如在此答案中所示：https://stackoverflow.com/a/11688523/357618 我已经使用仅存储保存对其进行了测试，但这看起来很有效，但是当列表中存在多个存储项时，这不起作用。
答案 0 :(得分：1)
Stash就像任何其他reflog条目一样，具有{revision}索引。
阅读here以获取有关reflog的一些信息。
git stash pop 从隐藏列表中删除单个隐藏状态并将其应用于当前工作树状态
git stash apply 与pop类似，但不会从隐藏列表中删除状态
git stash show 将存储中记录的更改显示为存储状态与其原始父级之间的差异
在您的情况下，您需要使用stash@{<revision>}来执行您希望执行的任何存储操作。
例如：
git stash show -p stash@{0}
答案 1 :(得分：0)
看起来它应该有效（但 不 工作，并且不容易制作工作;我稍后会解释原因。
作为一般规则，值得尝试将相同的参数直接传递给git rev-list以查看 是否可以将其解析为SHA-1。如果您这样做，您将再次收到相同的错误消息，但这将确认git stash中没有发生的事情，而且它更通用了。
这里是问题的根源：git＆＃39; s stash滥用git的提交DAG。 （＆＃34;滥用＆＃34;可能有点强，但我认为这是正当的。 1 ）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提交包含索引状态，w提交包含工作树状态。提交w是一个合并提交，即使它与合并无关;每个D的第一个父级是分支上提交（F或i），第二个是refs/stash提交。
请注意，此处只涉及一个git引用，即git stash。可能会说另一件事stash被滥用（在这种情况下我认为更少滥用，因为我们已经通过提交DAG滥用而遇到麻烦）是git的reflogs：stashes除了最新的stash@{0}或stash@{1}之外，只是reflog条目：stash@{2}，revspec^{/text}，等等。
在任何情况下，git rev-parse语法都会指示revspec从给定的 text 开始，然后向后遍历提交图，寻找提交邮件包含给定的 ... - A - B - C - D <-- branch
|\__
| \ \
| i-w <-- stash@{0}
|\
i-w <-- stash@{1}
。在你的情况下，毫无疑问在同一个分支上都会产生这些东西 - 比如：
w或许 - 但重点是从这些D ork-tree提交的 开始，向后遍历将检查提交C，然后提交{{1} }，然后是B，然后是A，依此类推。它根本不会打到其他藏匿处！即使两个存储袋悬挂在两个不同的提交中，也是如此：
... - A - B - C - D <-- branch
|\ |\
i-w i-w
从挂起D的存储包开始，转发列表行走是（第二个）w，然后是D，C，{{1} }，B等等。从挂起A的那个开始，它是（第一个）B，然后是w，然后是B，依此类推。
无论如何，简短的回答是提交文本搜索适用于提交图，而不是reflog，并且git的存储是通过reflogs完成的。如果A使用不同的方法来保留提交及其父项，那可能会使其工作，但更改此操作将非常重要（特别是您必须在某些过渡期支持多个存储表单）。
1 我声称“＆＃34;滥用＆＃34; 和实际滥用本身是合理的。这个词似乎是合理的，因为这些存储袋并不真正合并，它们只是作为合并存储，因此git stash代码可以方便和可恢复的形式保存两个甚至三个工作树。虐待本身似乎是合理的，因为这样可以完美地挽救树木并使其变得方便和可恢复。