1

I stupidly aborted a forgotten rebase with commits and uncommitted changes both on top of it, so it blew everything away, similar to questions like this.

I know about the reflog and immediately went to look in there, however it contained only a single hash of a non-useful pre-rebase state. What is going on? How can I lose reflog entries?

EDIT: in response to @kan below, here's roughly what I did:

git checkout badbranch
git rebase master
# CONFLICT, realized branch was bad and not needed anymore, but did not rebase --abort!
git branch -D badbranch
git checkout goodbranch
# some commits and edits here
git commit -av
# notices "you are currently rebasing" in the commit message
git rebase --abort # DOH
git reflog

The reflog only contains a8f06a6 HEAD@{2}: rebase: updating HEAD now

Community
  • 1
  • 1
Arkadiy Kukarkin
  • 2,153
  • 14
  • 24
  • `git fsck` was of no help :( – Arkadiy Kukarkin Apr 02 '14 at 22:03
  • Description quite vague, could you show us history of commands you done? – kan Apr 02 '14 at 22:03
  • Did you `git log` anytime during the rebase? This will sometimes save me. Look back through your terminal buffer for any commit id(s) from the rebase. Create tags for each of them so that `git log` will show them to you (and any commits that came before them). Then look at the full git log and (hopefully) find your missing commits. Than rebase or cherry-pick the missing commits back into master. – Bert F Apr 02 '14 at 22:46
  • Unfortunately I don't have the commit ids in the scrollback. I am starting to suspect that the actual commit objects are somehow lost as well, too. – Arkadiy Kukarkin Apr 02 '14 at 23:20
  • What about the reflog for `goodbranch`? (although there should be reflog entries for `HEAD` too, so this is puzzling) – torek Apr 02 '14 at 23:45
  • The reflogs for all involved branches are like this. It seems like something caused them to spuriously expire? – Arkadiy Kukarkin Apr 03 '14 at 17:46

1 Answers1

0

This should be clearer with Git 2.39 (Q4 2022):

See commit 9a1925b, commit 6159e7a, commit be0d29d, commit 33f2b61, commit 1f2d5dc, commit da1d633, commit 4e5e1b4, commit 57a1498 (12 Oct 2022) by Phillip Wood (phillipwood).
See commit a524c62 (17 Oct 2022) by Junio C Hamano (gitster).
(Merged by Taylor Blau -- ttaylorr -- in commit 8851c4b, 30 Oct 2022)

rebase --abort: improve reflog message

Signed-off-by: Phillip Wood

When aborting a rebase the reflog message looks like

rebase (abort): updating HEAD

which is not very informative.
Improve the message by mentioning the branch that we are returning to as we do at the end of a successful rebase so it looks like.

rebase (abort): returning to refs/heads/topic

If GIT_REFLOG_ACTION is set in the environment we no longer omit "(abort)" from the reflog message.
We don't omit "(start)" and "(finish)" when starting and finishing a rebase in that case so we shouldn't omit "(abort)".

So git reflog should be of better help in your case, starting with Git 2.39 (Q4 2022).

Also, still with Git 2.39 (Q4 2022), avoid setting GIT_REFLOG_ACTION to improve readability of the sequencer internals.

See commit 0e34efb, commit d188a60 (09 Nov 2022) by Phillip Wood (phillipwood).
(Merged by Junio C Hamano -- gitster -- in commit ff84d03, 23 Nov 2022)

rebase: stop exporting GIT_REFLOG_ACTION

Signed-off-by: Phillip Wood
Reviewed-by: Ævar Arnfjörð Bjarmason
Signed-off-by: Taylor Blau

Now that struct replay_opts has a reflog_action member we no longer need to export GIT_REFLOG_ACTION when starting a rebase.
If the user has set GIT_REFLOG_ACTION then we use it when initializing reflog_action.

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