Git 一个隐藏条目如何作为头提交和索引的子提交'；谁来承诺？

说

隐藏项表示为提交，其树记录状态 它的第一个父目录是头部的commit 创建条目时。第二个父级的树记录 创建项时索引的状态，并且该项是的子项 头犯了罪。祖先图如下所示：

       .----W
      /    /
-----H----I

其中H是头commit，I是记录状态的commit 索引，W是记录工作状态的提交 树

在本例中，隐藏项是否由commit

W

表示

隐藏项的commit

W

有两个父项

I

和

H

是什么意思

W

是否是（双向或三向）合并两个提交的结果

I

和

H

谢谢

在本例中，隐藏项是否由commit W表示

是或更恰当地说，否，它由commit

W

和commit

I

表示，但

W

足以找到

I

。无论是

W

还是

I

都足以找到

H

，而

git stash

将自动找到所有三个提交

隐藏项的commit

W

有两个父项

I

和

H

是什么意思

没什么特别的。这使得

git stash apply

和其他

git stash

函数查找

I

和

H

变得非常简单

文档中未显示的是第三次提交隐藏。第三次提交是可选的；仅当您使用了

-a

/

--all

或

-u

/

--包括未跟踪的

时，才会出现此选项。第三次提交是

W

的第三个父级。隐藏代码将测试第三个父级是否存在，以确定该隐藏是两次提交的还是三次提交的

（第三次提交（如果存在的话）的形式是根提交，因为它没有父级。它也很特别，因为它只保存未跟踪的文件，也可能根据您使用的标志被忽略，根本不保存任何工作树文件。我通常称第三次提交为

U

）

W

是否是（双向或三向）合并两个提交的结果

I

和

H

不是。隐藏代码只是在使用（滥用？）合并提交使用的表单，但目的不同：将两个（有时是三个）提交插入一个易于检查的表单中，以便隐藏代码进行检查。然后，特殊名称

refs/stash

可以保存

W

commit的散列ID，其他commit位于该散列ID中

---

（

git stash

代码使用特殊的临时索引文件来提交

W

和

U

。提交

I

更容易：它只需直接运行

git write tree

和

git commit tree

。

当我执行

git stash列表时--pretty=full--parents--full history

，我在每次提交时只看到一个父级，并且该父级SHA始终与列表中的下一次提交相匹配。我认为我所看到的隐藏中的所有东西都是工作树的隐藏，而不是任何索引阶段或两者的组合。

git stash list-p

实际上向我展示了垃圾。它显示了完全错误的差异。我只是做了两个简单的单行更改。我安排了其中一个，让另一个继续工作。一个

git的藏匿物是否保存了原油。当我执行git stash show-p时，它正确地将这些更改显示为差异。如果I
git stash list-p
，则它显示了对
cruft
的一组完全错误的更改：它显示了一个涉及多个文件的更改集，将版权声明推迟到2019年：我之前对这个分支做了几次修订，但根本没有隐藏。@Kaz:
git stash list-p
被隐藏提交的形式是合并，而不是合并这一事实弄糊涂了。如果您意外地运行了
git-show-stash
而不是
git-stash-show
，则会出现相同的问题。这种情况经常发生在我身上：我可能有点运动障碍。：-）@torek
git show stash
是一种东西吗？显然，它的意思似乎与git show stash@{0}

相同。我从中得到了diff-of-diff语法。

git-show

shows-commits（好吧，现在它几乎显示了所有内容！）<如果存在

refs/stash

，则code>stash是一个有效的引用，并且它指向隐藏的

W

提交。因此，

git show stash

显示了stash提交，并且由于它看起来像一个合并，

git show

将其视为一个合并。