Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
Run an interactive, root, rebase, select one or more commits to edit, and then leave the repo in the rebase state for long
enough that the "onto" commit expires out of the reflog and gets gc'd.
An example set of commands to immediately reproduce the issue can be seen below:
$ mkdir git_test
$ cd git_test
$ git init
Initialized empty Git repository in /Users/cfretz/working/git_test/.git/
$ git commit --allow-empty -m 'root commit'
[master (root-commit) 01edd93] root commit
$ git rebase -i --root
Stopped at 01edd93... root commit # empty
You can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
$ git reflog expire --expire-unreachable=now --all
$ git gc --prune=now
Enumerating objects: 2, done.
Counting objects: 100% (2/2), done.
Writing objects: 100% (2/2), done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
$ git rebase --continue
fatal: could not parse 10796537ce108c36191d52368250f403afede30b
What did you expect to happen? (Expected behavior)
Git should consider the "onto" commit to be referenced from the ongoing rebase, and refuse to gc it, even during a --root
rebase.
What happened instead? (Actual behavior)
Git gcs the "onto" commit, breaking the ongoing rebase; after this, no rebase commands work, and your only option is git rebase --quit.
The only way I've discovered to fix this without git rebase --quit is running scary commands to manually create a new dummy "onto" commit,
and then overwrite the onto file in the git directory; I'm not confident that this doesn't somehow cause subtle problems that aren't
immediately obvious.
What's different between what you expected and what actually happened?
Git gcs the onto commit and leaves the repo in a broken state. Without manual intervention to fix the .git directory, or hard bailing out of
the rebase, the repository appears broken. A user less familiar with git would likely just delete the repo, reclone, and start entirely from
scratch.
Anything else you want to add:
The way I originally encountered this issue was by leaving a repo in the rebase state for multiple weeks, coming back to the repo to finish the
work, and then having the repo broken by a background gc job. I assume the fundamental problem here is that the "onto" commit during a --root
rebase isn't actually a part of the new history, and is just "synthesized" to remove edge cases, and so git sees it as unreachable during the gc.
>From one perspective, it might be argued that this is "expected" behavior given the above, but given the severity of the failure I think this should
be considered a bug, and I think git should just unconditionally consider the "onto" commit as _always_ being reachable; it's not obvious to me why
this wouldn't work. My apologies if this bug has already been fixed in a later version of git. Thanks!
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.37.3
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:42:11 PST 2023; root:xnu-8792.81.3~2/RELEASE_X86_64 x86_64
compiler info: clang: 13.1.6 (clang-1316.0.21.2.5)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]
