Re: error: failed to run repack

[Eric Wong <e@80x24.org>]

Ali Alnubani <alialnu@mellanox.com> wrote:
> > -----Original Message-----
> > From: Eric Wong <e@80x24.org>
> > Sent: Tuesday, June 11, 2019 10:25 PM
> > To: Ali Alnubani <alialnu@mellanox.com>
> > Cc: meta@public-inbox.org
> > Subject: Re: error: failed to run repack
> > 
> > Ali Alnubani <alialnu@mellanox.com> wrote:
> > > Hi,
> > >
> > > I keep seeing the following in my logs for multiple lists:
> > >
> > > timestamp public-inbox-watch[PID]: Auto packing the repository in
> > background for optimum performance.
> > > timestamp public-inbox-watch[PID]: See "git help gc" for manual
> > housekeeping.
> > > timestamp public-inbox-watch[PID]: error: The last gc run reported the
> > > following. Please correct the root cause timestamp public-inbox-
> > watch[PID]: and remove path/to/repo.git/git/0.git/gc.log.
> > > timestamp public-inbox-watch[PID]: Automatic cleanup will not be
> > performed until the file is removed.
> > > timestamp public-inbox-watch[PID]: fatal: Failed to write bitmap
> > > index. Packfile doesn't have full closure (object
> > > 817390f628f74a55c627f1ddab8a44aa029753a0 is missing)
> > 
> > Do you have a path/to/repo.git/git/0.git/objects/info/alternates ?
> No:
> repo.git$ find . -name alternates
> ./all.git/objects/info/alternates

OK, thanks for that followup.  I wonder if there's something
else strange going on; or a git bug...

> > Bitmaps won't work when packing a repo with alternates In other words,
> > does 817390f628f74a55c627f1ddab8a44aa029753a0
> > exist in your 0.git, or somewhere else?
> This object doesn't exist in the filesystem:
> find . -name 817390f628f74a55c627f1ddab8a44aa029753a0
> But does exist as a commit in repo.git/git/0.git.

Erm, yeah, I just meant if it was in a pack somewhere, not a
loose object.

Did you have any crashes or failed fast-import processes?

> > The normal epoch repos (git/[0-9]+.git) aren't created with alternates by
> > default; instead all.git uses git/[0-9]+.git as alternates.
> Yes, this is the case in my repos.
> > 
> > > timestamp public-inbox-watch[PID]: error: failed to run repack
> > >
> > > Running 'git-fsck -full' in path/to/repo.git/git/0.git doesn't report any
> > issues.
> > >
> > > I imported my archives using scripts/import_vger_from_mbox.
> > >
> > > Any clue? Also is it safe to attempt a manual git-gc?
> > 
> > You might have the same result.  You can probably disable bitmaps in
> > all.git/config and set it in a git repo that does have full closure.
> 
> `git -c gc.reflogExpire=now gc --prune=all` inside repo.git/git/0.git finished successfully.
> Counting objects: 255747, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (92077/92077), done.
> Writing objects: 100% (255747/255747), done.
> Reusing bitmaps: 256, done.
> Selecting bitmap commits: 83010, done.
> Building bitmaps: 100% (321/321), done.
> Total 255747 (delta 84903), reused 237858 (delta 78421)
> 
> repo.git/git/0.git$ git count-objects -Hv
> count: 0
> size: 0 bytes
> in-pack: 255747
> packs: 1
> size-pack: 121.41 MiB
> prune-packable: 0
> garbage: 0
> size-garbage: 0 bytes
>  
> I deleted the file gc.log afterwards. I will keep monitoring
> if gc fails and the file is created again.

OK, so everything works for now and I guess it's not easily
reproducible anymore?

Did the gc+prune expire commit 817390f628f74a55c627f1ddab8a44aa029753a0 ?

I'm also wondering if you used the new public-inbox-edit or
public-inbox-purge.

In the future, it would also be good to note the git version
in use and also to Cc: git@vger.kernel.org