1

我遇到了交互式 rebase 的麻烦：因为我无法通过以下方式中止交互式 rebase

git rebase -i --abort

我尝试过了

git reset --hard ORIG_HEAD

但是，当我运行 git status 时，我现在得到

On branch feature1
You are currently rebasing. 
 (all conflicts fixed: run "git rebase --continue")

nothing to commit, working tree clean

有没有办法可以将 git 重置为交互式 rebase 之前的状态？

4

3 回答 3

1

在 Git 2.30（2021 年第一季度）之前，“ git rebase -i” （man）没有ORIG_HEAD正确存储。

请参阅Phillip Wood ( )的提交 8843302、提交 a2bb10d、提交 f3e27a0、提交 e100bea（2020 年 11 月 4 日） 。（由Junio C Hamano 合并 -- --在提交 c042c45中，2020 年 11 月 18 日）phillipwood
gitster

rebase -i: 停止覆盖ORIG_HEAD缓冲区

报告人：Caspar Duregger
签字人：Phillip Wood

变基后，ORIG_HEAD应该指向变基分支的旧 HEAD。
用于find_unique_abbrev()获取旧 HEAD 的对象名称并写入 .git/rebase-merge/orig-head （用于rebase --abort返回到先前状态）和ORIG_HEAD. 不幸的是，返回
的缓冲区是易失性的，并且在写入前一个文件之后但在写入之前被覆盖，从而在其中留下了不正确的对象名称。find_unique_abbrev()ORIG_FILE

避免依赖 volatile 的缓冲区find_unique_abbrev()，而是提供我们自己的缓冲区来保存对象名称。

我认为head_hash实际上应该使用的所有用户都应该使用opts->orig_head，因为传递一个字符串而不是一个结构object_id是脚本实现的遗留问题。
这个补丁只是修复了直接的错误，并添加了基于Caspar 的重现示例的回归测试。在接下来的几次提交中，用户将被转换为使用 structobject_id并被删除。head_hash

注意：来自Git 邮件列表：

git-rebase -i
# edit XYZ
git-reset HEAD~
git-commit -C ORIG_HEAD -a
git-rebase --continue
git-show ORIG_HEAD

ORIG_HEAD不指向重新定位分支的前一个 HEAD。
ORIG_HEAD 指向XYZ

" git reset" 将在重置之前将 ORIG_HEAD 更新为当前 HEAD，因此此处ORIG_HEAD更新为指向XYZ.

可以使用reflog在 rebase 后获取 rebase 分支的前一个 HEAD。
在 rebase 之后，branch-name@{1}将立即指向 pre-rebase HEAD。

于 2020-11-22T01:43:15.137 回答
0

我看到了这个问题，我发现了一个类似问题的顶部，它为我解决了这个问题。

git rebase --quit
于 2020-07-02T18:11:00.960 回答
0

我找到了解决问题的方法：

我通常在 Windows 命令行中使用 Git Portable。运行git rebase --abort或git reset --hard最后一次提交在那里没有效果。git status还是暴露了我的身份rebasing。

然而，git reset --hard在最后一次提交时切换到 Git Portable 的 bash-shell 让我回到了git status.

于 2016-12-12T17:06:09.237 回答