[BUG] "commit graph is likely corrupt" on git rebase

Hi Florian,

Florian Schmidt <[email protected]> wrote:
> Hiya,
> 
> Hitting an issue during git rebase. I am starting to suspect git is 
> possibly getting confused between main and submodule repos. I noticed 
> this with a self-compiled git 2.54, but I compiled git v2.55 just now, 
> and seem to hit the same issue still. Full bisect at the end of the message.
> 
> The first-order issue, trying to rebase a work/foo branch which is 
> tracking origin/master.  There's only one commit difference, a commit 
> that changes two submodule pointers:
> 
>> devvm:~/gitrepo[git:work/foo *%|u+1-116]$ git show --format="" -p
>> diff --git a/rpmsrc/kernel b/rpmsrc/kernel
>> index d8d411244..17006b605 160000
>> --- a/rpmsrc/kernel
>> +++ b/rpmsrc/kernel
>> @@ -1 +1 @@
>> -Subproject commit d8d411244cfb3463ce09b9577970f7955073ed14
>> +Subproject commit 17006b605eaed1820ae1c717d4782728b9afc6d3
>> diff --git a/rpmsrc/qemu-kvm b/rpmsrc/qemu-kvm
>> index e7d525d0f..8bf4019df 160000
>> --- a/rpmsrc/qemu-kvm
>> +++ b/rpmsrc/qemu-kvm
>> @@ -1 +1 @@
>> -Subproject commit e7d525d0fdc42fca65c2b70bb5f56adc5aa1d7b1
>> +Subproject commit 8bf4019dfcb320108a0f014d92d926320a4c8058
>> 
>> devvm:~/gitrepo[git:work/foo *%|u+1-116]$ git rebase
>> error: Could not read 157b7492624beac3ac667dd3a84de9969377866b
>> fatal: invalid commit position. commit-graph is likely corrupt
>> 
>> devvm:~/gitrepo[git:work/foo *%|u+1-116]$ git cat-file -t 157b7492624beac3ac667dd3a84de9969377866b
>> fatal: git cat-file: could not get object info
> 
> git fsck reported no corruption, just a bunch of dangling 
> commits/trees/blobs, no warnings about 
> 157b7492624beac3ac667dd3a84de9969377866b
> 
> Now, hint 1: the rebase *does* work when disabling commit-graphs:
> 
>> devvm:~/gitrepo[git:work/foo *%|u+1-116]$ git -c core.commitGraph=false rebase origin/master
>> Rebasing (1/1)
>> [... thinking thinking thinking for a long time ...]
>> Failed to merge submodule rpmsrc/kernel
>> CONFLICT (submodule): Merge conflict in rpmsrc/kernel
>> Failed to merge submodule rpmsrc/qemu-kvm
>> CONFLICT (submodule): Merge conflict in rpmsrc/qemu-kvm
>> [...]
> 
> which is fair enough, the submodule pointers moved.
> And hint 2:
> 
>> $ git cat-file -t 157b7492624beac3ac667dd3a84de9969377866b
>> fatal: git cat-file: could not get object info
>> $ git -C rpmsrc/kernel cat-file -t 157b7492624beac3ac667dd3a84de9969377866b
>> fatal: git cat-file: could not get object info
>> $ git -C rpmsrc/qemu-kvm cat-file -t 157b7492624beac3ac667dd3a84de9969377866b
>> commit
> 
> So it tries to identify something on the submodule? Maybe it gets 
> confused between submodule and main repo(?)
> 
> For good measure, I did a git fsck --full on rpmsrc/qemu-kvm, but again 
> only a few dangling warnings, and no change to the issue.
> So I went to bisect and noticed the issue appeared somewhere between 
> v2.53 and v2.54. v2.53 also complains, but then continues:
> 
>> $ ~/upstream/git/git rebase
>> error: Could not read 157b7492624beac3ac667dd3a84de9969377866b
>> error: Could not read 95d676ad199191d81a000761733ea25c17172d8b
>> Failed to merge submodule rpmsrc/kernel (commits don't follow merge-base)
>> CONFLICT (submodule): Merge conflict in rpmsrc/kernel
>> Failed to merge submodule rpmsrc/qemu-kvm (commits don't follow merge-base)
>> CONFLICT (submodule): Merge conflict in rpmsrc/qemu-kvm
>> [...]
> 
> In any case, to figure out the cause, I bisected it down to commit 
> bb5da75d61 ("commit: use commit graph in 
> `lookup_commit_reference_gently()`"), which makes sense in the context 
> of "it works with commit-graph disabled".

It’s usually a good idea to CC the commit author when you bisect a regression (I’ve CC’d Patrick)


> At this point, I wonder what the best next step is. I notice that there 
> are two errors listed even when the "git rebase" works on v2.53.0, which 
> are not there in the commitGraph=false case. I wonder whether that's a 
> sign that something deeper is not as it should be. I'm happy to provide 
> more details as needed, but I didn't want to touch the repo at this 
> point and possibly lose the repro.

A good next step would be to try to write a from-scratch reproducer :)

Cheers,

Philippe.