From: Phillip Wood <phillip.wood123@gmail.com>
To: Christopher Fretz <cfretz@icloud.com>, git@vger.kernel.org
Subject: Re: git rebase --root bug
Date: Thu, 11 May 2023 15:21:11 +0100 [thread overview]
Message-ID: <288a9935-264b-4dc5-0d63-200c310f326e@gmail.com> (raw)
In-Reply-To: <5E3AD305-8461-496F-B165-7734D400C4A6@icloud.com>
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]
next prev parent reply other threads:[~2023-05-11 14:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 20:08 git rebase --root bug Christopher Fretz
2023-05-10 20:35 ` Kristoffer Haugsbakk
2023-05-11 4:07 ` Christopher Fretz
2023-05-11 14:21 ` Phillip Wood [this message]
2023-05-11 16:16 ` Taylor Blau
2023-05-11 19:52 ` Christopher Fretz
2023-05-12 15:18 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=288a9935-264b-4dc5-0d63-200c310f326e@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=cfretz@icloud.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).