git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* BUG: commit-graph.c:1068 when doing `git pull`
@ 2020-11-02 18:30 herr.kaste
  2020-11-02 19:12 ` herr.kaste
  0 siblings, 1 reply; 4+ messages in thread
From: herr.kaste @ 2020-11-02 18:30 UTC (permalink / raw)
  To: git

Hi all!

I'm stuck with this error message

    $ git pull
    BUG: commit-graph.c:1068: missing parent
104f5eb377763b2ed9663e8949aed265b69f000f for commit
c59ed9b7b6d4268ae6cb1069a9b51e02ad9aa1d8

This happens since the last `fetch --prune origin`.

If I do it again, I get

    $ git pull
    fatal: Unable to create 'C:/Users/c-flo/AppData/Roaming/Sublime
Text 3/Packages/GitSavvy/.git/objects/info/commit-graphs/commit-graph-chain.lock':
File exists.
    ...

And upon removing that file, I get the first error message again.

I actually don't know yet how to move on from here.  I'm stuck, so I
appreciate any help.

    $ git --version
    git version 2.29.2.windows.1


Regards
Caspar Duregger

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: BUG: commit-graph.c:1068 when doing `git pull`
  2020-11-02 18:30 BUG: commit-graph.c:1068 when doing `git pull` herr.kaste
@ 2020-11-02 19:12 ` herr.kaste
  2020-11-12 14:42   ` Taylor Blau
  0 siblings, 1 reply; 4+ messages in thread
From: herr.kaste @ 2020-11-02 19:12 UTC (permalink / raw)
  To: git

A

    $ git commit-graph write

did the trick.

Let me know if you think there could be something useful to reproduce,
somewhere.

Regards
Caspar Duregger

Am Mo., 2. Nov. 2020 um 19:30 Uhr schrieb herr.kaste <herr.kaste@gmail.com>:
>
> Hi all!
>
> I'm stuck with this error message
>
>     $ git pull
>     BUG: commit-graph.c:1068: missing parent
> 104f5eb377763b2ed9663e8949aed265b69f000f for commit
> c59ed9b7b6d4268ae6cb1069a9b51e02ad9aa1d8
>
> This happens since the last `fetch --prune origin`.
>
> If I do it again, I get
>
>     $ git pull
>     fatal: Unable to create 'C:/Users/c-flo/AppData/Roaming/Sublime
> Text 3/Packages/GitSavvy/.git/objects/info/commit-graphs/commit-graph-chain.lock':
> File exists.
>     ...
>
> And upon removing that file, I get the first error message again.
>
> I actually don't know yet how to move on from here.  I'm stuck, so I
> appreciate any help.
>
>     $ git --version
>     git version 2.29.2.windows.1
>
>
> Regards
> Caspar Duregger

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: BUG: commit-graph.c:1068 when doing `git pull`
  2020-11-02 19:12 ` herr.kaste
@ 2020-11-12 14:42   ` Taylor Blau
  2020-11-12 16:27     ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 4+ messages in thread
From: Taylor Blau @ 2020-11-12 14:42 UTC (permalink / raw)
  To: herr.kaste; +Cc: git

Hi Caspar,

On Mon, Nov 02, 2020 at 08:12:07PM +0100, herr.kaste wrote:
> A
>
>     $ git commit-graph write
>
> did the trick.
>
> Let me know if you think there could be something useful to reproduce,
> somewhere.

I think this is worth trying to reproduce. The first message you're
seeing about the commit-graph-chain.lock already existing is a
red-herring: it's likely that the last time you tried to generate a
commit-graph, that it hit that same BUG() and left the stale lock laying
around. (I can't remember off the top of my head whether we still run
the atexit handlers upon a BUG(), but even still, I could believe that
some other stray process left it laying around, too).

So, what's interesting is why your commit graph ended up in a state that
it got some commit without all of its parents. If you could reproduce
that state, that would be interesting.

Are you using shallow or partial clones?

> Regards
> Caspar Duregger
>
> Am Mo., 2. Nov. 2020 um 19:30 Uhr schrieb herr.kaste <herr.kaste@gmail.com>:
> >
> > Hi all!
> >
> > I'm stuck with this error message
> >
> >     $ git pull
> >     BUG: commit-graph.c:1068: missing parent
> > 104f5eb377763b2ed9663e8949aed265b69f000f for commit
> > c59ed9b7b6d4268ae6cb1069a9b51e02ad9aa1d8
> >
> > This happens since the last `fetch --prune origin`.
> >
> > If I do it again, I get
> >
> >     $ git pull
> >     fatal: Unable to create 'C:/Users/c-flo/AppData/Roaming/Sublime
> > Text 3/Packages/GitSavvy/.git/objects/info/commit-graphs/commit-graph-chain.lock':
> > File exists.
> >     ...
> >
> > And upon removing that file, I get the first error message again.
> >
> > I actually don't know yet how to move on from here.  I'm stuck, so I
> > appreciate any help.
> >
> >     $ git --version
> >     git version 2.29.2.windows.1
> >
> >
> > Regards
> > Caspar Duregger

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: BUG: commit-graph.c:1068 when doing `git pull`
  2020-11-12 14:42   ` Taylor Blau
@ 2020-11-12 16:27     ` Ævar Arnfjörð Bjarmason
  0 siblings, 0 replies; 4+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2020-11-12 16:27 UTC (permalink / raw)
  To: Taylor Blau; +Cc: herr.kaste, git, Derrick Stolee


On Thu, Nov 12 2020, Taylor Blau wrote:

> Hi Caspar,
>
> On Mon, Nov 02, 2020 at 08:12:07PM +0100, herr.kaste wrote:
>> A
>>
>>     $ git commit-graph write
>>
>> did the trick.
>>
>> Let me know if you think there could be something useful to reproduce,
>> somewhere.
>
> I think this is worth trying to reproduce. The first message you're
> seeing about the commit-graph-chain.lock already existing is a
> red-herring: it's likely that the last time you tried to generate a
> commit-graph, that it hit that same BUG() and left the stale lock laying
> around. (I can't remember off the top of my head whether we still run
> the atexit handlers upon a BUG(), but even still, I could believe that
> some other stray process left it laying around, too).
>
> So, what's interesting is why your commit graph ended up in a state that
> it got some commit without all of its parents. If you could reproduce
> that state, that would be interesting.

No matter how it got to that point we shouldn't be dying on a "git pull"
just because the commit-graph code had a hickup. I thought I'd addressed
this in 43d3561805 ("commit-graph write: don't die if the existing graph
is corrupt", 2019-03-25) and related commits, but I see that's not the
case.

That code really needs to learn how to operate in two different
modes. One in the write/verify codepath where we're the primary command
being called, and one where we're just being called on
fetch/pull/status/whatever when we shouldn't hard die just because we
can't access the commit-graph side data.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-11-12 16:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-02 18:30 BUG: commit-graph.c:1068 when doing `git pull` herr.kaste
2020-11-02 19:12 ` herr.kaste
2020-11-12 14:42   ` Taylor Blau
2020-11-12 16:27     ` Ævar Arnfjörð Bjarmason

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 NNTP newsgroup(s).