1

I got myself into trouble with an interactive rebase: Since I could not abort the interactive rebase via

git rebase -i --abort

I tried to

git reset --hard ORIG_HEAD

However, when I run git status, I now get

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

nothing to commit, working tree clean

Is there a way I can reset git to the status before the interactive rebase?

Albert
  • 85
  • 6
  • What if you `continue` the `rebase` and then set your branch again to track remote which will remove the changes of `rebase`? – Deepesh Dec 12 '16 at 13:22
  • Sorry, what do you mean by setting to track remote? git rebase --continue gives me: `Already applied: 0000 fatal: ambiguous argument '': unknown revision or path not in the working tree` – Albert Dec 12 '16 at 13:45

3 Answers3

1

Before Git 2.30 (Q1 2021), "git rebase -i"(man) did not store ORIG_HEAD correctly.

See commit 8843302, commit a2bb10d, commit f3e27a0, commit e100bea (04 Nov 2020) by Phillip Wood (phillipwood).
(Merged by Junio C Hamano -- gitster -- in commit c042c45, 18 Nov 2020)

rebase -i: stop overwriting ORIG_HEAD buffer

Reported-by: Caspar Duregger
Signed-off-by: Phillip Wood

After rebasing, ORIG_HEAD is supposed to point to the old HEAD of the rebased branch.
The code used find_unique_abbrev() to obtain the object name of the old HEAD and wrote to both .git/rebase-merge/orig-head (used by rebase --abort to go back to the previous state) and to ORIG_HEAD.
The buffer find_unique_abbrev() gives back is volatile, unfortunately, and was overwritten after the former file is written but before ORIG_FILE is written, leaving an incorrect object name in it.

Avoid relying on the volatile buffer of find_unique_abbrev(), and instead supply our own buffer to keep the object name.

I think that all of the users of head_hash should actually be using opts->orig_head instead as passing a string rather than a struct object_id around is a hang over from the scripted implementation.
This patch just fixes the immediate bug and adds a regression test based on Caspar's reproduction example. The users will be converted to use struct object_id and head_hash removed in the next few commits.

Note: from the Git mailing list:

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

ORIG_HEAD does not point at the previous HEAD of the rebased branch.
ORIG_HEAD points to XYZ

"git reset" will update ORIG_HEAD to the current HEAD before resetting so here ORIG_HEAD gets updated to point to XYZ.

One can use the reflog to get the previous HEAD of the rebased branch after rebasing.
Immediately after the rebase, branch-name@{1} will point to the pre-rebase HEAD.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

I found a solution to my problem:

I am normally using Git Portable in a Windows command line. Running git rebase --abort or git reset --hard on the last commit had no effect there. git status still revealed that I am in status rebasing.

However, switching to the bash-shell of Git Portable, git reset --hard on the last commit brought me back to a non-rebasing status of git status.

Albert
  • 85
  • 6
  • It sounds like your "helpful" environment made `git rebase --abort` not work. In any case `git reset --abort` is the normal way to do this (no `git reset` required afterward). – torek Dec 12 '16 at 18:47
0

I was seeing this issue and I found a top on a similar question that fixed it for me.

git rebase --quit
tnolte
  • 1