从藏匿,奇怪的结果重新开始

Question

我只是出于好奇而问这个问题.在现实生活中还有其他方法来处理这种情况,但我发现git的以下行为有点奇怪.

简介: Stashing在幕后创建了两个提交,一个包含索引,另一个包含非添加的编辑.如果我们检查后者并尝试重新定义它,我们只能从索引中获取更改.这是为什么？

详细示例如下:

首先让我们使用一次提交创建一个repo,然后再添加一个编辑添加到index,然后再添加一个未添加到index的编辑,然后使用stash:

git init
echo 1 > a.txt
git add a.txt
git commit -m"First commit"
echo 2 >> a.txt
git add a.txt
echo 3 >> a.txt
git stash
git log --all --graph --oneline

  *   5c00fc0 WIP on master: c8af537 First commit
  |\  
  | * 965c986 index on master: c8af537 First commit
  |/  
  * c8af537 First commit

因此git stash似乎将索引和非添加的编辑保存为具有自己的哈希的提交(在我的情况下,对于索引为965c986,对于未添加的编辑为5c00fc0).

现在编辑一个新文件并提交:

echo x >> b.txt
git add b.txt
git commit -m"Second commit"

所以所有的提交现在看起来像:

git log --all --graph --oneline

  * b589f50 Second commit
  | *   5c00fc0 WIP on master: c8af537 First commit
  | |\  
  |/ /  
  | * 965c986 index on master: c8af537 First commit
  |/  
  * c8af537 First commit

比如说,我们现在想要进行隐藏编辑并将它们与第二次提交相结合.还有其他方法可以做到这一点(比如git stash apply,但是,如果我们已经清理了存储,然后从reflog中挖掘了提交,那么,让我们尝试:

git checkout 5c00fc0
[warning message here]
cat a.txt
  1
  2
  3
git rebase master
  First, rewinding head to replay your work on top of it...
  Applying: index on master: c8af537 First commit

但现在,生成的文件a.txt只是:

cat a.txt 
  1
  2

这是整个图表:

git log --all --graph --oneline
  * 5fc3ade index on master: c8af537 First commit
  * b589f50 Second commit
  | *   5c00fc0 WIP on master: c8af537 First commit
  | |\  
  |/ /  
  | * 965c986 index on master: c8af537 First commit
  |/  
  * c8af537 First commit

所以看起来,即使我们检查了提交5c00fc0,rebase只应用了提交965c986的更改,即我们存储时索引中的编辑.但是5c00fc0中的任何内容都被忽略了.

问题:为什么？对这种行为有一些合理的解释吗？或者这应该被视为一个错误？

Answer 1

事实证明，git 在变基时只是（默认情况下）忽略合并提交。存储会创建 WIP 提交和索引提交，并且 WIP 提交是合并，因为它同时将索引提交和 c8af537 作为父级。

与藏匿无关。