Re: git fetch --prune fails with "fatal: bad object"

From: Jeff King <peff@peff.net>
Date: Jun 6, 2024, 01:14 UTC
Message-ID: <20240606011453.GA623737@coredump.intra.peff.net>
In-Reply-To: <c2a02982-40a9-6629-05c2-c8de3335f35b@fastmail.fm>

On Wed, Jun 05, 2024 at 04:43:45PM -0700, Fred Long wrote:

Show 10 quoted lines

> On 6/5/2024 1:47 AM, Jeff King wrote:
> > 
> > Your local refs should not point to missing objects, though. Each clone
> > should maintain its own consistency. Are you using "git clone --shared"
> > or another scheme involving alternates?
> > 
> I use Google's "repo" script to manage Android repositories. The "repo"
> script runs "git repack -a -d", and I think that's what's removing the
> commits locally. Remotely, our bitbucket server removes commits that are no
> longer referenced.

Using "git repack -a -d" by itself should retain the objects that are reachable from your local refs/remotes/ refs. But I'd suspect that "repo" is doing something clever under the hood. I know there's some support for alternates, and a quick (hah!) "repo init && repo sync" on the android manifest shows that we end up symlinked objects directories. So there is ".repo/projects/foo.git" whose objects directory is a symlink to ".repo/project-objects/foo.git/objects".

I don't know how it is all supposed to work, but naively running "git repack -a -d" in the "project-objects" version risks corrupting the "projects" version, because it has no idea what refs are in the latter.

Certainly this warning is ominous:

  https://gerrit.googlesource.com/git-repo/+/refs/tags/v2.45/docs/internal-fs-layout.md#project-objects

-Peff