From: Michael Forney <mforney@mforney.org>
To: Alex Riesen <alexander.riesen@cetitec.com>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>,
Gary Oberbrunner <garyo@oberbrunner.com>
Subject: Re: Possible git bug in commit-graph: "invalid commit position"
Date: Sun, 21 Jun 2020 13:45:01 -0700 [thread overview]
Message-ID: <CAGw6cBuEshq18O_PrrGYuJi5VZ82XK3T9KuShneUqO2Ju0jtHw@mail.gmail.com> (raw)
In-Reply-To: <20200515120333.GA4677@pflmari>
On 2020-05-15, Alex Riesen <alexander.riesen@cetitec.com> wrote:
> Gary Oberbrunner, Tue, Feb 04, 2020 23:33:42 +0100:
>> Sorry for the long reply delay; the bug went away and only just showed
>> up again. Here's the info you requested.
>> I'm now running git 2.25.0.
>
> I hit a very similar problem today with 2.26.0. Also in a submodule.
>
> Removing and regenerating the commit graph did not help and I did not have
> the
> commit-graphs directory (only a file). "git commit-graph verify" does not
> find
> anything. Switching writeCommitGraph on and regenerating the commit graph
> makes no difference.
>
> I can trigger it reliably by visiting the broken(?) commit in supermodule
> with:
>
> git show --submodule=log <commit>
>
> I see nothing special in the commit invovled. It is just a single commit in
> my
> case, and the commit is a merge of two branches.
I hit this bug a while back, and it went away after I deleted the
commit-graph in the submodule and regenerated it (IIRC).
I just ran into it again (on 2.27.0), and this time, I did some digging.
I have a repository containing a number of submodules, and the bug
appeared after I updated one of the submodules, and then looked at
`git log -p` with diff.submodule = log. Just like Alex, I can reliably
trigger the error with `git show --submodule=log <commit>`.
I rebuilt git with some print statements to try to see what's going
on, and got the following:
/src/oasis/.git/modules/pkg/file/src c81d1ccbf4c224af50e6d556419961dba72666c7
pos: 4986, num_commits: 6452, num_commits_in_base: 0
/src/oasis/.git/modules/pkg/file/src 9f2f793847c6aeab9501287b6847dc842c84630f
pos: 3964, num_commits: 6452, num_commits_in_base: 0
/src/oasis/.git/modules/pkg/file/src fd7eb1f793944635b92bfa56a84a4dc1dbefb119
pos: 6383, num_commits: 6452, num_commits_in_base: 0
/src/oasis/.git/modules/pkg/file/src d955cefc956ba537cfc0556023a65fe80bd2d82b
pos: 5436, num_commits: 6452, num_commits_in_base: 0
/src/oasis/.git/modules/pkg/file/src 0c79c693d6a86f7ad7ada2a9a1eb3bdf483f77cc
pos: 301, num_commits: 6452, num_commits_in_base: 0
.git fa09b87efa9b9664e4e53ab768cfa5f51a6c6fa2
pos: 6292, num_commits: 5177, num_commits_in_base: 0
fatal: invalid commit position. commit-graph is likely corrupt
Using `git commit-graph verify`, I confirmed that the main
repository's commit graph contains 5177 commits, and the submodule
repository's commit-graph contains 6452 commits. Commit fa09b8 is part
of the submodule, not the main repository, so it makes sense that it
is an invalid commit for the main repositories commit-graph.
So, this seems a little fishy. fill_commit_in_graph is getting called
with the main repository and a commit belonging to the submodule.
Looking through the call stack in gdb, I see that the initial calls to
fill_commit_in_graph come from show_submodule_header, which computes
left, right, and merge_bases. Then, those commits are passed to
prepare_submodule_summary, but this function does *not* accept a
submodule parameter. prepare_submodule_summary calls
repo_init_revisions with the_repository, which seems to be the source
of the problem. I think it should be using the submodule repository
instead.
I changed prepare_submodule_summary to accept a repository and to use
that instead, but the issue persisted. Digging deeper, this is because
revision.c:process_parents uses parse_commit_gently, which is a
synonym for repo_parse_commit_gently(the_repository, ...). I changed
it to use repo_parse_commit_gently(revs->repo, ...), and this time,
the problem went away.
I'm not very familiar with the git codebase, but am I on the right
track here? I also noticed a number of other calls to
parse_commit_gently in revision.c, and I think those should pass
revs->repo as well. Does that sound right? If so, I can send a patch
to fix these issues.
-Michael
next prev parent reply other threads:[~2020-06-21 20:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFChFygiaMsUJC5Kfpnk26DLWbY0gPdNJpZ_gLMf4utZ6_oZxA@mail.gmail.com>
2020-01-20 17:32 ` Fwd: Possible git bug in commit-graph: "invalid commit position" Gary Oberbrunner
2020-01-21 0:37 ` Derrick Stolee
2020-02-04 22:33 ` Gary Oberbrunner
2020-05-15 12:03 ` Alex Riesen
2020-06-21 20:45 ` Michael Forney [this message]
2020-06-22 13:45 ` Derrick Stolee
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGw6cBuEshq18O_PrrGYuJi5VZ82XK3T9KuShneUqO2Ju0jtHw@mail.gmail.com \
--to=mforney@mforney.org \
--cc=alexander.riesen@cetitec.com \
--cc=garyo@oberbrunner.com \
--cc=git@vger.kernel.org \
--cc=stolee@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).