Re: git rebase --root bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christopher

On 10/05/2023 21:08, Christopher Fretz wrote:
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

The cause of the problem is that --root creates an empty commit (known as "squash_onto" in the code) which it uses as the "onto" commit. When it picks the first commit in the todo list the "onto" commit is amended and so is unreachable when the reflog is expired above. I think the best fix would be to stop pretending that we have a real "onto" commit when --root is used without --onto and either store "new root" .git/rebase-merge/onto or not create that file at all.

Best Wishes

Phillip

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]



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux