“git pull --rebase --autostash”不应该总是自动弹出存储吗？即使有冲突？

Posted 2023-02-19

【中文标题】“git pull --rebase --autostash”不应该总是自动弹出存储吗？即使有冲突？

【英文标题】：Shouldn't "git pull --rebase --autostash" always pop the stash automatically? Even when there are conflicts?

【发布时间】：2021-12-23 06:42:10

【问题描述】：

在几年前的上一份工作中，我们使用 git 和一个（旧）插件，称为“git up”。https://github.com/aanand/git-up “不再维护或支持此插件。” 更新您的工作区曾经非常容易： 只需输入“git up”，查看哪些文件有冲突，编辑这些文件以解决冲突，执行“git add”，就完成了。

我现在在另一家公司工作。他们今年早些时候开始使用 git。 我们没有一个清晰而简单的方法让每个人都可以更新我们的工作空间。 我想介绍一种非常简单的方法来更新您的工作区。 尽可能简单。没有提交，没有合并。

似乎最简单的方法是使用带有 --rebase 和 --autostash 标志的“git pull”。 您可以通过在 .gitconfig 文件中设置这些值来执行相同操作。 或使用别名：

git config --global alias.up '!git fetch && git rebase --autostash origin'

这有点工作。 当没有冲突时，存储会自动弹出。 除了输入“git up”或“git pull --rebase --autostash”之外，我不需要做任何事情。

有一个问题。 当发生冲突时，git 拒绝将存储应用回我的工作区。 它说：

Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" at any time.
Successfully rebased and updated refs/heads/main.
$ git stash list
stash@0: autostash
$ 

当我然后键入“git stash pop”时，存储会弹出，我的本地更改会自动再次编辑到我的工作区中（使用通常的 >>>> 和

注意，当我更改了远程存储库上也更改的文件时，git 总是拒绝自动弹出存储。不仅存在真正的冲突（在同一行上进行更改）。但是，当我的更改远不及远程存储库的更改时。这让我怀疑我看到的行为真的不是故意的。

但是为什么 --autostash 不会自动弹出存储？ 我与公司的 git 支持人员进行了交谈。 他们还希望存储自动弹出。 即使有冲突。 我做了一些谷歌搜索。我发现没有任何迹象表明存储不应自动弹出。

所以我的问题： 我能期待什么？ 当我使用 --autostash 时，stash 是否应该总是自动弹出？ 还是我看到的行为正常？ 这是一个错误吗？ 我们本地的 git 团队是否更改了可执行文件或全局配置中的某些内容？ （他们说他们没有）。

行为与 2.26.2 和 2.33 相同。谢谢。

【参考方案1】：

你看到的行为（呃，行为）是正常的，因为操作仍在进行中。操作完成后，应该弹出（或者更确切地说，丢弃）自动存储。确实，在这种情况下，rebase 部分操作已经完成，但是 stash 没有干净地应用，所以git stash apply 步骤失败了：

Applying autostash resulted in conflicts.

（我认为Git 做了一个git reset --hard 来消除对git stash apply 的尝试，让你在这一点上自己做，但我不使用自动存储。请注意，运行git stash pop 将获得冲突，并且只会应用，而不是丢弃隐藏。）

我个人不喜欢 autostash，因为它过于复杂：它包含一个多步骤操作，包括进行 stash 提交、变基，然后应用和删除 stash 提交。我建议您在变基之前提交，而不是stash。这样，最后一次提交是变基的一部分，因此只需完成一个操作。

您可以在完成所有操作后使用git reset 删除重新定位的提交，如果这甚至需要的话：我喜欢较小的提交，以便稍后在它们“准备好迎接黄金时段”时合并，并在我正在进行的工作中留下一堆小的“这不是我想要的，但它是进步”的承诺有助于解决这个问题。最终，我运行git rebase -i 或一系列git rebase -i 来对迷你提交进行排序和合并。

（不要让这成为针对git stash 的小型咆哮，但是...git stash 本身通常很糟糕。避免它。）

【讨论】：

所以输入“git pull --rebase --autostash”过于复杂。但是做 git add, git commit, git fetch, git rebase, git reset, git rebase -i，让你的更改分布在多个差异上（可能还有更多“方便”的技巧）很容易吗？我喜欢简单的东西。我也希望我的同事简单。如果 autostash 总是自动弹出，键入一个命令将是完美的。我仍然不明白为什么“git up”插件可以更新您的工作区并自行合并更改/冲突。而“git pull --rebase --autostash”不能。

Git，唉，并不简单，试图让它变得简单总是失败。问题本身——分布式源管理——并不简单。 Git 比必要的复杂一点：Mercurial 得到了一些“正确”的东西，就像它一样。但除了大多数 Git 教程和介绍很糟糕之外，大多数 Git 可见的复杂性并不是无缘无故的。

git 不简单的事实并不意味着它不应该简单。如果我们一直保持这种态度，我们仍然会使用汇编程序进行编程（“唉，编程并不简单”）。让我们不要讨论这个问题。你无法说服我。我只需要用 git 做 3 件事（克隆、更新和创建拉取请求）。所以我认为（前两个）应该用一个简单的单行命令来触发。旧的“git up”插件可以做到这一点。我们可以手动应用存储。那么为什么 autostash 不能不做 autopop 呢？我看不出为什么不这样做。它会让 90% 的 git 用户的生活变得更简单。

所以没人有什么好说的吗？除了：“我不喜欢你做事的方式”和“git 很难而且令人困惑，习惯它”。我一直在寻找 git 的半官方支持论坛。您可以报告错误或请求功能的联系点。我没有找到。有人知道我可以去哪里吗？强制“git rebase --autostash”始终弹出的标志或选项就足够了。

你问了一个相对简单的问题，回答是或否（“它应该这样做”），答案是“是的，它应该这样做”。 有一个 Git 邮件列表用于报告错误或请求功能，但这不是 Stack Overflow。

【参考方案2】：

事实证明这是一个错误。使用 autostash 时，stash 应该会自动弹出。即使有冲突。正如我所料。今年早些时候（或去年）的某个地方，有人破坏了该功能。我检查了 git 源代码的最新版本（“下一个”）。并且弹出再次自动发生。

还有一个问题。在弹出之后，并且在没有问题地应用更改之后，我希望存储也会自动被删除（删除）。那不会发生。不知道是故意的，还是bug。我怀疑这是一个错误。如果一切正常，为什么要保留藏匿处？我敢打赌没有人知道，也没有人敢决定要不要解决这个问题。

可悲的是：我问了一大群人当前的行为（没有自动弹出）是故意的还是错误的。同事，安装/维护我们的 git 的人，我们内部的 git 支持人员，我们本地的 git 专家，我们的外部 git 支持团队。和这里。我得到了无数的答案。没有一个是正确的。大多数人甚至没有回答这个问题：“我不喜欢 rebase，我不喜欢 autostash，我不喜欢 stash，你为什么不做我做的事情，这样更好”。没有人真正回答我的问题。我不怪这里试图回答的人，但是在逆流而上的两个月之后，我有点恼火。对不起。

我很高兴我坚持了下来。我很高兴这个问题很快就会得到解决。现在剩下的唯一事情就是确保当我们不再需要它时，它会被丢弃。如有必要，我会自己修复它并将修复程序提供给 git 存储库。