重置为ORIG_HEAD后，git仍处于状态重定位状态

Question

我使用交互式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之前的状态？

Answer 1

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

我通常在Windows命令行中使用Git Portable。在上次提交时运行git rebase --abort或git reset --hard对此没有影响。 git status仍然显示我处于rebasing状态。

但是，在最后一次提交中切换到Git Portable的bash-shell，git reset --hard会让我回到git status的非重新定位状态。

Answer 2

我看到了这个问题，并在a similar question的顶部找到了一个可修复的问题。

git rebase --quit

Answer 3

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

请参见commit 8843302的commit a2bb10d，commit f3e27a0，commit e100bea，Phillip Wood (phillipwood)（2020年11月4日）。
^{（由Junio C Hamano -- gitster --在commit c042c45中合并，2020年11月18日）}

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

^{报告人：Caspar Duregger
签名人：Phillip Wood}

重新建立基础之后，ORIG_HEAD应该指向重新建立分支的旧HEAD。
该代码使用find_unique_abbrev()获取旧HEAD的对象名，并写入.git / rebase-merge / orig-head（rebase --abort使用以返回到先前的状态）和{ {1}}。
不幸的是，ORIG_HEAD返回的缓冲区是易失的，并且在写入前一个文件之后但在写入find_unique_abbrev()之前被覆盖，从而在其中保留了错误的对象名称。

避免依赖ORIG_FILE的易失性缓冲区，而应提供我们自己的缓冲区来保留对象名称。

我认为find_unique_abbrev()的所有用户实际上应该使用head_hash而不是传递字符串而不是结构opts->orig_head，这是脚本实现的难处。 br /> 该修补程序仅修复了即时错误，并基于Caspar's reproduction example添加了回归测试。在接下来的几次提交中，用户将被转换为使用结构object_id和object_id。